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ABSTRACT 


Formal  Techniques  in  the  Management  ol  Software  Design 


William  E.  Richardson 


Merton  College 


Doctor  of  Philosophy 


Trinity  Term  1983 


The  inordinately  high  cost  of  software  continues  to  be  the  major 
shortcoming  in  the  development  of  computer  systems.  In  the  past,  attempts 
to  solve  this^software  crlsls^have  been  from  one  of  three  independent 
approaches  —  using  structuring  techniques  or  using  formal  techniques 
(together  these  two  are  called  software  engineering)  or  using  management 
techniques,  it  is  now  apparent  that  this  ^management-technology  decoupllng*^- 
is  avoidable  and  that  a  viable  software  design  methodology  must  include 
mutually  supportive  management,  structuring,  and  formal  components.  This 
thesis  attempts  to  develop  just  such  a  methodology  for  the  design  of  large 
systems.  Jlc. 

First,  we  proposers  set  of  criteria  which  will  be  use  to  evaluate  design 
methodologies.  Based  on  these  criteria  and  research  into  existing 
methodologies,  we  then  outlines*  our  new  methodology.  It  utilizes  the 
advantages  of  high  level  abstraction,  an  extensible  set  theoretical  notation, 
hierarchical  structuring,  and  numerous  management  techniques.  A  simple 
example  is  given  to  Introduce  the  design  style  and  notation. 

in  order  to  assess  the  new  methodology  A^nd^oi{%  interaction  of 

management  and  software  engineering  techniques,  -we  tfo  a  case  study 

development  of  a  windowed,  information  sharing  display  and  filing  system.  ^ 
This  development  has  as  its  starting  point  a  simple  but  very  powerful 

abstraction  which  could  be  used  as  the  basis  for  any  similar  system.  The 

abstraction  is  presented  with  an  appropriate  natural  language  explanation  so 
that  it  could  be  a  self  contained  entry  in  a  library  of  high  level  abstractions. 

On  the  basis  of  the  case  study,  we  give  a  partial  assessment  of  the 
methodology  against  the  stated  criteria.  Two  existing  methodologies  are  also 
assessed  for  comparison. 
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CHAPTER  I 


Introduction 

Today's  major  shortcoming  In  the  development  of  computer  systems 
is.  just  as  it  was  ten  years  ago.  the  cost  of  the  software.  Far  from  having 
been  solved,  this  problem  appears  to  be  growing  more  critical  as  the 
proliferation  of  computer  systems  increases  at  an  unprecedented  rate.  It  is. 
therefore.  Imperative  that  we  strive  to  define  and  implement  a  practical 
software  development  methodology  which  consolidates  the  technical  and 
management  gains  we  have  made  In  the  software  development  field.  The 
overall  aim  of  this  thesis  Is  to  contribute  to  the  design  of  just  such  a 
methodology.  In  particular,  we  investigate  the  practical  application  and 
management  of  formal  software  techniques  within  a  development  methodology 
for  large  scale  sequential  software  systems. 

1.1  The  Problem. 

At  present,  it  is  estimated  that  75%  of  the  purchase  price  of  an  off 
the  shelf  computer  system  is  allocated  to  the  cost  of  the  softwareIBoehm.811. 
Often  more  than  50%  of  this  software  expense  comes  from  the  cost  of 
maintenance  (either  repair  or  enhancement.)  The  decade  from  1980  to  1990 
will  see  (in  the  US.  for  example)  a  six-fold  increase  in  the  computer  and 
information  processing  industry(Boehm,81).  This  means  that  at  the  current 
cost  ratios,  the  US  in  1990  will  be  spending  about  $120,000,000,000  per  year 
on  software  maintenance.  However,  as  hardware  becomes  economically 
feasible  for  more  applications  and  as  the  scarcity  of  trained  personnel 
intensifies,  overall  software  costs  are  very  likely  to  increase  significantly  faster 
than  even  this  prediction  would  lndlcateIWasserman.81;  Dlstaso.80).  it  is  also 
likely  that  the  percentage  of  the  software  budget  consumed  by  maintenance 
will  Increase  to  as  much  as  80%  in  this  decade(Pressman,82). 


Of  course,  only  the  direct  costs  of  software  development  are  defined 
in  these  statistics.  Of  equal  or  greater  importance  are  the  Indirect  costs. 
These  result  from  loss  of  business  due  to  late  delivery  or  software  failure, 
disruption  of  the  client's  organization,  system  misuse  or  difficulty  of  use. 
system  failure  to  keep  user's  trust,  etc.  Although  these  costs  are  of  great 
significance  they  cannot,  in  general,  be  accurately  measured. 

The  cost  of  software  will  continue  to  be  the  weak  link  in  the  computer 
system  development  chain  and  may  even  retard  the  growth  in  computer 
applications  if  it  continues  to  climb.  Stabilization  and  eventual  decrease  of 
overall  cost  requires  a  corresponding  increase  in  software  development 
productivity,  reliability,  and  ease  of  adaptation,  along  with  an  increased 
concern  for  the  Indirect  costs  attributable  to  software  production  and  use. 

1.2  The  Solution. 

a.  History. 

Previous  attempts  to  deal  with  the  crucial  problem  of  software  cost 
have  been  numerous  and  varied.  In  general,  these  cost  limiting  strategies 
fall  into  one  of  two  approaches  —  software  engineering  or  management. 
This  separation  of  approaches  has  been  called  the  ’management-technology 
decoupling.*  (Boehm. 76] 

For  our  purposes,  software  engineering  can  be  defined  as  the 
application  of  scientific  ('engineering-like')  principles  to  any  stage  of  software 
design  and  maintenance.  Two  general  forms  of  software  engineering 
techniques  have  been  proposed  —  structuring  techniques,  which  are 
processes  to  guide  and  delimit  the  software  during  development,  and  formal 
techniques,  which  are  well  formulated  scientific  or  mathematical  processes 
involving  the  use  and  manipulation  of  meaningful  symbols.  In  general,  the 
software  engineering  approach  has  the  goal  of  improving  the  readability, 
verifiability,  reliability,  and  maintainability  of  the  software. 

Structuring  techniques  are  based  on  the  general  theory  that  ’the 
structure  of  the  program  itself  is  the  single  most  important  determinant  of 
the  lifecycle  costs  of  a  software  project.*  [Bergland.81;iil]  These  techniques 
attempt  to  enforce  a  division  of  labor,  allow  informal  reasoning  about  program 
parts,  and  allow  the  substitution  of  equivalent  modules  within  a  program. 


A  few  of  the  structuring  techniques  which  have  been  applied  with  success 
to  different  aspects  of  the  software  development  process  are: 
decomposition/modularization  [Parnas.72] 

goto-less  programming  (Dijkstra.68) 

structured  programming  (Dahl. 72) 

stepwise  refinement  [Wirth.711. 

The  formal  techniques  suggest  a  two  part  approach  to  the  problem: 
the  first  part  Is  production  of  the  design  specification,  the  statement  that 
formally  embodies  the  system  requirements  and  defines  the  behavior  of  the 
system.  The  second  part  is  the  formal  verification  that  the  Implemented 
software  rigorously  adheres  to  the  specification  of  the  design. 

'The  formal  methods  seek  to  do  for  programming  what  mathematics  has  done 
for  engineering:  provide  symbolic  methods  whereby  the  attributes  of  an  artifact 
can  be  described  and  predicted.*  [Berg.82;D 

One  or  more  symbolic  notations  and  the  mathematical  methods  to  manipulate 
the  notation  must  be  incorporated  Into  any  viable  formal  technique.  (See 
lGoguen.80]  or  [Berg. 82]  for  a  further  discussion  of  what  is  desirable  in  such 
a  formal  symbology.)  A  few  of  the  representations  which  have  been  proposed 
for  use  in  formal  techniques  include: 

CLEAR  [Burstall.801 

set  theory  [Abrial.821 

SPECIAL  [Levitt] 

temporal  logic  [Manna.80] 

algebraic  specifications  [Horning. 80] 

META-IV  [Bjorner.82] 

The  management  approach  adheres  to  the  philosophy  that  general 
and  applied  management  practices  are  effective  for  controlling  software 
development  and  its  associated  cost.  Proponents  of  this  approach  stress  that 
*it  is  fundamentally  a  management  problem  to  insure  that  the  product  will 
In  fact  be  what  the  user  wants.'  (Cave. 78]  Often,  unlike  the  software 
engineering  approach,  management  a  -ategies  will  focus  on  the  software 
development  and  maintenanc  '  *>ce  itself  rather  than  the  resulting  software. 
That  is.  with  the  management  approach,  cost  reduction  occurs  generally  as 
a  result  of  a  simplified  or  more  efficient  development  process  rather  than 


the  development  of  a  superior  Implementation.  Experience  has  shown, 
however,  that  a  simplified  development  technique  may  also  have  the  secondary 
effect  of  promoting  better  programs.  Although  the  management  approach  Is 
by  far  the  most  varied  and  arguably  the  most  successful  of  the  current 
attempts  at  moderating  software  costs,  it  has  become  obvious  that  there  are 
no  purely  management  solutions  to  technical  problems.  A  few  of  the  numerous 
management  strategies  which  have  been  practically  applied  are: 
egoless  programming  [Weinberg. 69J 

chief  programmer  teams  [Baker.72] 

unit  development  folders  [lngrassia.78J 

walk-throughs  [Yourdon.78). 

In  conjunction  with  these  approaches  to  minimizing  software  costs, 
automated  tools  and  program  development  environments  have  been  created. 
Such  tools  are  generally  designed  to  effect  a  savings  by  simplifying  and 
enforcing  either  a  software  engineering  or  a  management  strategy.  To  date, 
the  achievements  of  such  tools  have  been  limited  as  a  result  of  two  serious 
shortcomings[Wasserman.82]: 

1.  They  fail  to  support  a  software  development  methodology  or  assist 
in  the  control  of  a  software  development  process. 

2.  They  fail  to  support  the  entire  software  development  lifecycle. 
That  is.  such  tools  have  been  only  marginally  successful  because  they  are 
very  isolated  In  terms  of  their  scope  and  Integration  Into  the  overall 
development  process. 

This  brings  us  to  a  second  standard  by  which  we  can  categorize 
software  cost  reduction  strategies;  that  is.  the  extent  of  the  software  lifecycle 
over  which  the  strategy  Is  effectivelBergl.  A  method  is  a  strategy  which 
directly  affects  the  software,  design,  or  the  development  process  in  a 
restricted  portion  of  the  lifecycle.  A  strategy  or  coordinated  group  of 
strategies  which  consistently  influence  a  significant  portion  of  the  lifecycle 
is  called  a  methodology.  By  far.  the  larger  number  of  strategies  introduced 
have  been  methods  designed  to  influence  one  phase  of  the  lifecycle,  usually 


implementation.  However,  a  few  methodologies  have  been  defined;  for 
example: 

top-down  design  methodology 

Jackson  structured  design  methodology  [Jackson. 75} 

chief  programmer  teams  [Baker.721 

Hierarchical  Development  Methodology  (HDM)  [Silverberg] 

Rigorous  Methodology  [Jones. 80] 

Rational  Design  Methodology  (RDM)  [Boyd. a] 

USAF  Methodology  IUSAF] 


FIG.  1-1  —  Historical  Approaches  to  the  Software  Development  Problem. 

b.  Our  Approach. 

The  approach  taken  in  this  thesis  is  that  the  gap  between  the  software 
engineering  and  management  strategies  is  avoidable  and  can  be  bridged  with 
a  synergistic  result.  Further,  such  a  combined  strategy  Is  required  if  the 
critical  problem  of  software  cost  is  to  be  effectively  contained  in  the  design 
and  development  of  large  scale  application  software  systems.  Otherwise,  the 
problems  of  communication,  management  control  and  correctness  of  the 
product  grow  in  a  geometric  relation  to  the  size  of  the  projecUBrooks.751 


In  order  to  design  a  practical  combined  software 

engineering-management  approach,  we  have  adapted  or  developed  selected 
formal,  structuring,  and  management  methods  and  have  composed  them  Into 
an  integrated  whole.  The  resultant  methodology  combines  many  desirable 
cost  reducing  features  of  the  previously  independent  approaches.  These 
features  include: 

-  use  of  very  abstract  initial  designs  and  potential  reuse  of  previous 
abstraction  designs 

-  expanded  set  theoretical  formal  design  notation  which  allows  formal 
verification  and  testing  of  design  features 

-  separation  of  formal  verification  and  design  for  increased 

management  control 

-  vertical  and  horizontal  decomposition/recomposition  to  'divide  and 
conquer*  the  design  problem 

-  separation  of  design  and  implementation  decisions 

-  a  limitative  design  approach  to  constrain  the  complexity  of  the 

design 

-  use  of  baselines,  milestones  and  configuration  management  controls 
within  the  formal  design  process 

-  use  of  prototypes 

progressive  requirement  v.  jvetopmem  with  continuous  Client 

involvement 

-  continuous  design  documentation  with  an  explicit  statement  of  design 
decisions 

In  general,  this  approach  to  the  design  of  large  software  systems  attempts 
to  insure  that  'everyone  will  know  what  they  ouoht  to  know  when  they  ought 
to  know  It.* 


1.3  Thesis  Organization. 

in  Chapter  II  we  define  a  set  of  important  criteria  which  we  will  use 
to  assess  software  development  methodologies.  We  then  develop  the  main 
points  of  our  proposed  methodology,  giving  emphasis  to  the  interaction  among 
the  formal,  structural,  and  management  aspects  of  the  technique.  To  conclude 


the  second  chapter  we  present  a  simple  introductory  example  of  the  formal 
design  structure  and  notation.  In  the  third  chapter  we  define  a  very  abstract 
family  of  Information  sharing  filing  systems.  This  family  is  also  presented 
in  the  style  and  notation  of  the  proposed  methodology  and  forms  the  basis 
of  one  component  In  the  case  study  design  of  Chapters  IV  and  V.  Our  case 
study  is  the  design  of  a  windowed,  information  sharing,  visible  filing  system. 
It  demonstrates  an  application  of  the  methodology  to  a  reasonably  sized  design 
problem.  The  complexity  of  this  development  has  been  controlled  by 
eliminating  most  communication  requirements  (ie.  a  one  man  design  and 
implementation  with  a  hypothetical  client)  and  by  concentrating  on  the  unique 
components  of  the  methodology  during  the  first  half  of  the  software  life  cycle. 

in  Chapter  VI  we  evaluate  the  case  study  application  of  the 
methodology  and  extrapolate  these  conclusions  to  large  scale,  multi-man 
developments  over  the  full  lifecycle.  By  so  doing,  we  prepare  the  way  for 
more  substantial  tests  of  the  methodology.  Additionally,  in  this  chapter  we 
compare  the  proposed  development  technique  with  two  other  techniques  of 
interest:  the  methodology  currently  used  by  the  US  Air  Force  and  the 
Hierarchical  Development  Methodology  of  SRI  International. 

The  final  chapter  summarizes  the  significance  of  the  proposed 
methodology  as  an  approach  to  the  problem  of  software  cost  and  reviews 
other  contributions  of  this  research.  For  completeness,  a  sketch  of  possible 
future  research  is  given. 


CHAPTER  II 


Methodology 

Although  the  historical  approaches  listed  in  the  previous  chapter  gave 
us  some  general  guidelines,  substantial  further  research  was  required  to 
produce  a  practical  methodology  based  on  the  experience  gained  from  those 
approaches.  We  surveyed  the  significant  existing  software  design  techniques 
to  determine  if.  and  how.  they  attempted  to  satisfy  the  problems  of  large 
scale  software  system  development.  Then  we  defined  the  most  important 
criteria  by  which  to  judge  any  proposed  methodology.  These  criteria  are 
presented  in  the  following  section.  From  our  research  and  criteria  definitions, 
we  produced  a  set  of  basic  tenets  which  appear  to  collectively  define  an 
improved  software  development  methodology  for  large  systems.  Section  11.2 
contains  these  tenets  in  the  form  of  an  overview  of  the  important  aspects 
of  our  methodology.  The  reader  is  advised  that  the  recommended  approach 
to  Section  11.2  is  an  initial  quick  skim,  followed  by  a  more  detailed  perusal, 
it  required,  after  reading  the  methodology  overview  in  Section  11.3  and  the 
small  example  application  in  Section  11.4. 


11.1  Criteria. 

Each  of  the  historical  approaches  and  techniques  discussed  in 
Chapter  I  provides  a  partial  solution  to  the  software  development  problem; 
likewise,  each  lacks  some  advantage  provided  by  the  others.  Therefore,  in 
a  sense,  our  general  criteria  for  a  more  effective  software  development 
strategy  must  include  a  capability  for  structuring,  verifying,  and  managing  the 
development  process  consistently  throughout  the  lifecycle  of  the  software 
product.  However,  these  three  historical  strategies  are  much  too  specific 


and  are  occasionally  even  orthogonal  to  the  actual  characteristics  we  require 
to  meet  our  stated  goal  of  improved  software  development.  A  number  of 
other  attempts  to  develop  criteria  for  the  comparison  and  evaluation  of 
software  design  methodologies  have  produced  other  general  criteria.  Some 
of  these  criteria  can  be  found  In  (Berg. 80:  Boyd. a;  Carlson. 82:  Keeton. 80; 
Griffiths. 78;  Parker.78:  Peters. 79;  Pressman. 82).  etc.  In  all  cases,  the  criteria 
presented  by  these  authors  do  not  put  the  emphasis  In  the  area  of  software 
cost  reduction  or  are  too  general  to  be  of  use  to  us.  Consequently,  we 
have  formulated  our  own  criteria  to  emphasize  the  key  areas  as  determined 
by  our  research.  It  would  be  impossible  to  present  a  complete  set  of  criteria 
so  we  have  limited  ourselves  to  the  more  significant  ones. 

a.  Control  of  Creativity  And  Cumulativity. 

As  in  any  design  process,  software  design  is  a  combination  of  two 
activities  —  creation  (innovation)  and  reapplication  of  previously  designed 
components  or  reuse  of  concepts.  (The  example  of  architectural  design  often 
comes  to  mind  when  discussing  the  design  process.  Certainly,  it  is  easy 
to  relate  these  two  activities  to  the  design  of  a  building  or  a  bridge.)  The 
first  activity  is  highly  dependent  upon  the  utilization  of  human  intelligence 
and  cannot  generally  be  distilled  down  to  a  set  of  step-by-step  procedures. 
Consequently,  this  is  an  unpredictable  process  which  is  subject  to  error, 
backtracking,  and  multiple  Iterations,  and  is  difficult  to  manage.  Therefore, 
the  creative  nature  of  design  cannot  be  without  restraint,  and  must,  in  the 
end.  lead  to  the  objectives  of  correctness,  completeness,  robustness, 
maintainability,  adaptability,  economy,  etc.  At  the  same  time,  this  restraint 
cannot  be  guilty  of  stifling  the  creative  ability  of  the  software  engineer  either 
by  overly  complex  notation  or  by  drowning  him  in  a  morass  of  detail. 

The  second  activity  of  design  requires  previous  designs  be  available 
and  modifiable  to  fit  new  circumstances.  This  capability  for  reappllcation 
design  efforts  to  new  but  similar  problems  could  be  called  the  cumulativity 
of  a  design  field.  The  danger  inherent  in  not  requiring  a  design  process 
to  be  cumulative  Is  that  errors  are  repeated,  lessons  are  not  learned  through 
experience,  and  solutions  do  not  improve  even  though  the  problems  get  more 
complex  or  critical.  At  present,  in  spite  of  vigorous  pursuit  of  this  objective, 
the  cumulativity  of  software  design  has  remained  at  a  very  low 
level(8ranstad.81). 


Therefore,  a  software  design  methodology  should  provide: 

1.  a  technique  for  identifying  and  isolating  components  which  must 
be  creatively  designed. 

2.  an  environment  which  enhances  creativity  by  guiding  and 
structuring  but  does  not  overwhelm  the  creative  effort. 

3.  a  technique  for  expanding  the  reapplication  of  designs  (not  just 
programs(Parnas.75]) 

b.  Guaranteed  Product  Reliability. 

An  important  responsibility  of  any  design  methodology  is  to  adequately 
guarantee  the  reliability  of  the  design  and  its  implementation.  Put  slightly 
differently,  the  designer  should,  to  the  requisite  level,  validate  the  accuracy 
of  the  design's  representation  of  the  client's  requirements  and  verity  that 
implementations  accurately  correspond  to  the  designs.  It  is  significant  to 
note  that  the  communication  of  requirements  from  the  client  to  the  designer 
is  the  single  link  in  the  development  process  which  cannot  be  formalized; 
hence,  validation  will  always  remain  a  subjective  and  informal  task. 

Verification  can  be  either  Informal  or  formal.  Informal  verification 
is  an  attempt  to  find  and  correct  errors  early  in  the  design  and  Implementation 
stages.  Formal  verification  works  at  proving  the  mathematical  correctness  of 
the  Implementations  In  a  formal  notation.  However,  totally  formal  techniques 
are  expensive  to  the  point  of  being  impractical  for  use  on  large 
developments(Berg.82;  Pressman. 82].  The  true  advantage  in  reliability  afforded 
by  the  use  of  formal  specifications  is  in  the  discipline  it  imposes  so  that 
programs  need  not  be  proven  correct  so  much  as  developed  in  such  a  manner 
as  to  make  their  correctness  evldent(Dijkstra.76). 

Our  criterion  of  guaranteed  product  reliability  does  not  attempt  to 
dictate  absolute  correctness  of  the  design  and  implementation,  which  would 
be  an  unrealistic  standard.  Instead,  it  requires  that  management  can 
prescribe  and  control  the  level  of  reliability  for  individual  system  components. 
Consequently,  within  the  scope  of  a  methodology  the  development  manager 
should  be  able  to  dictate  the  rigor(Jones.80]  of  the  verification  and  (within 
limits)  the  granularity  of  the  specification.  From  this  we  can  see  that  formal 
and  management  framework  of  a  methodology  must  be  mutually  supportive 
and  cannot  just  be  allowed  to  coexist. 
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c.  Requirement  Evolution. 


'The  problem  of  generating  complete,  consistent,  unambiguous, 
testable  software  requirements  continues  to  plague  the  software  Industry  and 
remains  the  most  serious  challenge  to  bring  order  to  the  software  development 
process....  This  problem,  which  has  been  debated,  analyzed,  and  researched 
for  years,  is  Invariably  the  critical  factor  In  project  success  or  failure  for 
most  projects  of  significant  size.  [One  of]  the  key  elements  of  this  problem 
...  [is]  continually  changing  user  needs.*  [Dlstaso.80;  10) 

This  quotation  sums  up  well  the  critical  and  difficult  nature  of 
requirements  definition  in  the  software  development  process.  And  It  suggests 
why.  in  any  design  process,  requirements  definition  must  be  accomplished 
in  an  evolutionary  and  iterative  manner.  It  must  be  evolutionary  because 
requirements  are  usually  hierarchical  —  one  does  not  usually  stipulate  the 
size  of  the  master  bedroom  before  defining  the  style  of  the  house  he  wishes 
the  architect  to  design.  Each  new  level  of  requirement  builds  on  the 
preceding  levels  of  requirement  definition;  at  each  level  the  client  wants  to 
be  left  with  some  freedom  for  expressing  his  requirements  as  the  system 
takes  shape.  It  is  an  Iterative  process  because  backtracking  to  a  previous 
level  may  be  required  when  it  becomes  obvious  that  a  new  requirement  is 
contradictory  to  those  previously  defined.  This  view  of  requirements  definition 
as  evolutionary  and  iterative  leaves  one  wondering  how  It  differs  from  the 
process  of  hierarchical  design.  As  the  design  theorist  Rittel  stressed;  'A 
statement  of  the  problem  is  a  statement  of  the  solution. '[Rittel. 73]  If  the 
design  problem  statement  and  the  design  solution  statement  are  in  the  same 
terms  (ie.  both  formal,  both  in  natural  language  text,  both  In  graphical 
representation,  etc.)  they  are  essentially  equivalent  statements.  It  is.  therefore, 
not  only  unnatural  but  counterproductive  to  attempt  to  separate  formal 
requirements  definition  and  the  formal  design  process. 

The  client,  unless  he  is  highly  sophisticated  or  has  a  trivial  problem, 
is  likely  to  have  only  a  limited  initial  understanding  of  his  requirements  and 
will  undoubtedly  express  those  requirements  In  an  Incomplete  (and  often 
inconsistent)  manner  In  natural  language.  For  every  set  of  circumstances 
there  is  a  different  requirement  interpretation  for  each  different  client  (and 
a  different  design  interpretation  of  the  requirement  definition  for  each  different 
designer.) 

This  wide  variation  in  client  requirement  interpretation  impels  any 
design  methodology  which  starts  with  an  informal  requirement  definition  (as 
invariably  It  must)  to  allow  great  flexibility  In  its  formal  starting  point.  The 


key.  then,  in  the  difficult  transition  from  the  incomplete  informal  requirements 
definition  to  a  formal  definition  (le.  a  formal  design)  is  to  gain  confidence 
in  the  formal  translation  slowly.  In  an  evolutionary  manner  with  provision  for 
Iteration. 

d.  Continuity  Through  the  Lifecycle. 

Although  most  of  today's  software  cost  comes  from  the  maintenance 
end  of  the  lifecycle,  it  has  often  been  suggested  (eg.  [Buckie. 77])  that  a 
remedy  to  this  situation  will  require  a  concentrated  effort  in  all  phases  of 
software  development  and  In  the  early  phases  in  particular.  Hence,  any  viable 
methodology  must  cover  the  entire  life  of  the  software  system  but  must  also 
encourage  early  identification  of  critical  factors  In  the  design  process. 

Most  authors  include  some  combination  similar  to  the  following  in 
a  description  of  the  software  lifecycle:  problem  definition,  requirements 
specification.  design.  implementation.  test.  installation, 

maintenance/modification,  and  phase  out.  However,  the  separation  between 
the  various  lifecycle  phases  is  not  always  distinct;  and  this  is  especially  true 
between  requirements/design  [Peters.78;  Rlddle.78],  and  design/implementatlon 
[Swartout.82].  Optimally,  a  software  engineering  methodology  will  not  only 
consider  the  entire  lifecycle,  but  will  also  reflect  the  similarity  of  consecutive 
lifecycle  phases.  That  is.  if.  In  a  practical  sense,  design  is  indistinguishable 
from  requirements  specification,  then  the  techniques,  tools,  languages,  etc. 
used  in  the  methodology  should  be  the  same  for  both  of  these  phases. 

In  general,  a  verifiable  software  system,  throughout  Its  lifecycle,  will 
have  at  least  three  different  representations.  The  first  is  the  natural  language 
(or  at  least,  non-formal)  representation  of  the  client's  requirements.  The 
second  representation  is  the  formal  and  verifiable  language  of  specification. 
The  final  representation  Is  the  machine  executable  one  —  the  software  itself. 
(The  first  two  representations  are  required  as  the  documentation  of  the  third.) 
Consequently.  It  is  obvious  that  at  least  two  transitions  will  be  required  in 
a  methodology  which  attempts  to  deal  with  the  entire  software  lifecycle. 
Insuring  smooth  transitions  among  these  representations  Is  one  of  the  major 
tasks  of  any  methodology. 

In  sum,  a  viable  methodology  must  reduce  system  lifecycle  costs  by 
early  recognition  of  potential  design  difficulties  and  by  comprehensive 
enforcement  of  the  appropriate  design  procedures  throughout  the  life  of  the 
software  system.  These  procedures  must  reflect  the  life  stages  of  the  software 
and.  further,  must  minimize  the  disruptive  effect  of  representation  changes. 


e.  Continuous  Client  involvement. 

Yet  another  vital  element  must  be  considered  in  the  criteria  for  a 
good  design  methodology.  The  client  (user,  customer,  etc.)  is  the  driving  force 
behind  a  system  design  and.  hence,  the  supreme  fudge  of  any  software  effort. 
He  will  invariably  look  at  a  newly  developed  system  and  ask:  'Old  I  get  quality 
for  the  cost?"  A  design  methodology  must  attempt  to  create  a  relationship 
between  the  client's  perception  of  the  design  quality  and  the  design  cost 
which  weighs  heavily  on  the  side  of  quality.  This  cannot  be  done  formally 
but  experience  shows  that  the  best  way  to  succeed  In  this  task  Is  to  keep 
the  client  actively  involved  from  beginning  to  end  —  It  must  be  an  Interactive 
process  between  the  client  and  the  designer.  The  psychological  benefits 
(acceptence.  increased  satisfaction,  feeling  of  contrlbuting)[Shnelderman.80] 
and  the  actual  benefits  (reduced  training,  reduced  modification,  etc.)  from 
client  involvement  can  4>e  the  difference  between  success  and  failure  of  a 
software  project. 

As  we  noted  in  the  section  on  Requirements  Evolution,  the  client's 
view  of  the  problem  is  not  static.  This  point  is  also  succinctly  presented 
In  a  quote  from  (Peters.781: 

‘...Although  the  customer  may  state  his  requirements  very  firmly  at  the 
beginning,  his  perception  of  the  problem  begins  to  change  as  he  begins  to 
consider  how  the  solution  development  (ie.  design  and  perhaps  coding)  is 
proceeding.* 

Evolving  requirements  are  the  rule  rather  than  the  exception  in  large  scale 
application  software  development.  Obviously,  It  Is  Important  that  design  activity 
not  be  allowed  to  advance  faster  than  the  client's  requirements  evolve. 

Our  conclusion  Is  that  client  interaction  must  be  an  integral  part  of 
the  design  methodology.  This  communication  must  be  continuous,  and  it  must 
occur  in  both  directions.  And  finally.  In  order  to  keep  the  design  in  concert 
with  the  client's  view  of  the  requirements,  the  methodology  must  permit  the 
Judicious  postponement  of  design  decisions. 


f.  Manageability. 

Because  of  the  complexity  Inherent  In  the  development  of  large  scale 
software  systems,  the  ability  to  manage  that  complexity  within  the  framework 
of  a  methodology  is  mandatory.  For  our  purposes,  we  have  categorized  the 


areas  which  most  require  Inherent  manageability  within  the  discipline  of  the 
methodology  as: 

1.  visibility  and  control 

2.  budgeting  and  accountability 

3.  coordination  and  communication. 

The  first  area,  visibility  and  control.  Is  at  the  heart  of  process 
management  for  any  process.  Visibility  means  that  the  manager  can 
accurately  determine  the  status  of  the  design  effort  at  critical  points.  Control 
indicates  that  based  on  the  current  status  of  the  project  he  can  direct  the 
project  in  the  manner  which  best  suits  his  predetermined  goals.  In  other 
words,  the  methodology  must  give  the  design  manager  the  flexibility  to  select 
the  most  appropriate  compromise  from  the  conflicting  design  goals:  it  must 
give  him  the  capability  to  determine  if  the  design  is  progressing  toward  the 
compromise  he  has  selected;  and  finally,  it  must  give  him  the  capability  to 
redirect  the  design  effort  as  necessary  to  achieve  those  goals. 

The  manageability  of  the  resource  budgeting  and  accounting  in  a 
development  process  is  also  significantly  dependent  upon  the  visibility  of  the 
process.  In  general,  resource  control  in  a  process  requires  an  initial  estimate 
of  resource  allocation  (budgeting)  and  periodic  reviews  (accounting)  of 
resource  usage  followed  by  estimate  refinement.  A  methodology  which  does 
not  provide  the  capability  to  accurately  determine  resource  allocations  and 
allow  timely  review  of  resource  utilization  will  often  prove  dangerously 
uncontrollable. 

The  final  area  of  required  manageability  within  a  methodology  is  in 
communication  and  coordination.  As  noted  in  that  classic  of  the  software 
management  field.  {Brooks.75],  the  larger  the  project,  the  more  difficult 
communication  and  coordination  becomes.  We  previously  stressed  the 
importance  of  communication  with  the  client.  Also  of  significance  is 
management  control  over  the  communication  and  coordination  within  the 
development  team  (designers.  Implementors,  verifiers,  malntalners.  etc.)  A 
major  concern  here,  of  course,  is  with  the  style  and  standard  of  the 
documentation.  The  ultimate  answer  to  the  problem  of  documentation  is  that 
the  working  of  the  methodology  should  automatically  create  the  documentation 
in  the  form  required  without  management  Intervention.  Especially  Important 
in  the  documentation  would  be  the  explicit  declaration  of  decisions  and  their 
rationale. 


In  summary,  the  criterion  of  manageability  suggests  that  a  design 
methodology,  no  matter  how  complete  otherwise,  is  not  acceptable  unless  it 
allows  (or  better  still,  enforces)  the  process  control  required  by  management. 
A  methodology  must  view  the  software  development  process  as  a  whole,  not 
just  program  production  but  also  budgets,  schedules,  priorities,  operations, 
etc. 


Again,  it  should  be  emphasized  that  these  criteria  represent  a 
minimum  set  of  capabilities  we  feel  are  desirable  in  a  practical  and  viable 
software  design  methodology  in  order  to  effectively  reduce  the  cost  of  software 
development.  These  criteria  are  obviously  not  mutually  exclusive  and  in  some 
instances  may  even  represent  overlapping  or  conflicting  goals;  therefore,  the 
objective  of  determining  a  methodology  to  meet  these  criteria  is  an  inherently 
complex  task.  As  [Boehm. 81:23]  suggests. 

‘The  most  important  software  engineering  skills  we  must  learn  are  skills 
involved  in  dealing  with  a  plurality  of  goals  which  may  be  at  odds  with  each 
other,  and  the  skill  of  coordinating  the  application  of  a  plurality  of  means, 
each  of  which  provides  a  varying  degree  of  help  or  hindrance  in  achieving 
a  given  goal.* 

11.2  Software  Engineering  Basis. 

We  introduce  the  technical  concepts  which  form  the  software 
engineering  basis  of  our  methodology  In  the  following  subsections.  Standard 
management  concepts  will  not  be  explained  In  detail  since  they  can  be 
referenced  In  any  good  software  management  book  (eg.  (Jensen. 79; 
Donaldson. 78]).  In  the  Section  11.3  we  integrate  the  software  engineering  and 
management  aspects  Into  a  complete  design  system. 

a.  initial  abstraction. 

Initial  requirements  definitions  will  vary  greatly  in  completeness  and 
stability  depending  on  many  factors  outside  the  control  of  the  software 
engineer.  Perhaps  even  more  distressing.  It  is  often  Impossible  to  determine 
the  degree  of  trust  which  should  be  afforded  to  any  initial  problem  description. 
Consequently,  the  determination  of  how  abstractly  to  begin  the  design  is  one 
of  the  more  difficult  tasks  for  the  software  designer.  Our  methodology 
advocates  an  initial  abstraction  which  Is  more  general  than  appears  to  be 
indicated  by  the  initial  problem  requirements.  Although  no  reference  could 
be  found  of  any  other  software  design  methodology  taking  this  approach,  there 


are  a  number  of  reasons  for  assuming  that  it  is  reasonable  and  logically 
warranted. 

First,  the  proven  inadequacy  of  initial  requirement  definitions  and  the 
evolving  nature  of  requirements  make  It  necessary  to  give  the  designer 
sufficient  latitude  to  meet  the  client's  reasonable  requirements.  This  brings 
us  to  compare  the  additive  with  the  limitative  approach  to  design.  The  additive 
approach  espouses  the  philosophy  that  the  designer  should  adopt  a  meager 
Initial  design  and  add  capability  as  the  requirements  become  known.  This 
is  a  very  open-ended  and  undisciplined  design  technique.  On  the  other  hand, 
the  limitative  approach  suggests  that  an  initial  upper  bound  be  placed  on 
the  capabilities  of  the  design  and  that  excess  capacity  be  deleted  by  design 
decisions  as  the  requirements  evolve.  This  is  a  much  more  bounded 
approach;  therefore,  it  affords  greater  control  over  the  design  process  since 
a  finite  limit  on  the  design  scope  and  capacity  is  predefined.  As  a  simplified 
example  of  these  two  approaches,  consider  the  design  of  an  objective  test 
scoring  system.  The  additive  approach  might  be  to  represent  a  test  as  a 
list  (SEQ)  of  answers:  white  the  limitative  approach  would  begin  more 
abstractly,  perhaps  with  a  test  represented  by  a  relation  between  question 
numbers  and  answers.  In  the  former  approach,  the  decision  to  allow  questions 
with  multiple  or  no  correct  answer  will  necessitate  an  addition  to  the  formal 
representation  of  a  test;  however,  the  limitative  abstraction  could  be  restricted 
to  accommodate  this  reasonable  requirement.  In  practical  use.  a  methodology 
must  allow  both  approaches  but  should  build  where  possible  on  the 
management  advantages  of  the  limitative  technique.  This  suggests  that  an 
initial  abstraction  general  enough  to  cover  most  reasonable  client  requirements 
could  be  used  to  constrain  the  problem  and  allow  a  limitative  design 
technique. 

Secondly,  we  must  consider  the  client's  comprehension  of  the  system. 
Since  our  criteria  demand  that  the  client  be  Involved  throughout  the  design 
process,  it  is  important  that  he  understands  and  agrees  to  the  initial  design. 
The  absence  of  detail  which  characterizes  abstractions  makes  a  very  abstract 
design  generally  easier  to  explain  and.  hence,  a  better  basis  upon  which 
to  build  the  client's  mental  image  of  the  design. 

Thirdly,  we  should  note  that  any  formal  design  starting  point  will  hide 
decisions  by  implicitly  requiring  them  within  the  formalism.  As  a  very  simple 
example,  an  initial  abstract  design  of  a  Mst  (SEQ)  of  words  hides  the  decisions 
that  the  words  are  to  be  consecutive  and  are  numbered  starting  from  one. 
A  partial  function  from  natural  numbers  to  words  as  the  initial  abstraction 


hides  neither  of  those  decisions.  The  partial  function  representation  would 
have  to  be  explicitly  constrained  to  Include  these  decisions.  We  Insist  that 
any  significant  decision  must  be  explained  in  natural  language  before  it  Is 
defined  In  the  formalism  of  the  design.  Therefore,  we  must  attempt  to  limit 
hidden  decisions  to  those  which  are  trivial  or  obvious  by  using  very  general 
Initial  abstractions. 

Further,  the  flexibility  and  comprehensibility  of  a  highly  abstract  design 
make  it  a  good  candidate  for  use  as  a  starting  point  for  other  similar  design 
projects.  That  is.  software  design  cumulativity  could,  perhaps,  be  enhanced 
be  using  the  same  very  abstract  initial  design  for  various  similar  design 
problems. 


b.  The  Hierarchy. 

The  hierarchical  nature  of  our  design  methodology  is  a  result  of  a 
combination  of  two  types  of  decomposition,  horizontal  and  vertical[Goguen.80], 
Horizontal  decomposition  partitions  the  Initial  requirements  Into  modules  In 
order  to  control  the  complexity  and  manageability  of  the  design  task.  Vertical 
decomposition  divides  levels  of  detail  in  a  module  to  separate  and  order  the 
design  decisions.  For  example,  a  report  generator  design  might  be 
horizontally  decomposed  into  separate  modules  for  data  input,  data  base 
update,  and  report  output.  The  data  base  update  module  could  have  one 
vertical  level  which  records  decisions  about  the  required  relationship  among 
various  data  fields  in  the  data  base,  with  the  next  vertical  level  restricting 
the  number  of  each  type  of  record  allowed  in  the  data  base.  Horizontal 
decomposition  strives  to  create  totally  independent  modules  while  each  vertical 
level  Is  dependent  upon  the  previous  level  for  its  basis. 

b.1  Horizontal  decomposition. 

Horizontal  decomposition  reduces  the  design  problem,  where 
necessary,  to  a  set  of  equivalent  subproblems,  each  of  which  is  conceptually 
less  difficult.  This  type  of  decomposition  might  also  be  regarded  as  static 
decomposition  because  it  is  usually  accomplished  at  the  very  onset  of  the 
desip  process  and  ideally  is  not  changed  until  each  subproblem  is  solved. 
At  this  point  the  static  decomposition  is  undone  by  recomposition  of  the 
decomposed  components.  This  recomposition  is  required  to  demonstrate  that 
the  various  pieces  of  the  design  fit  together  in  the  manner  contemplated  when 
they  were  decomposed. 


The  problem  of  how  to  horizontally  decompose  a  requirement 
influences  the  problem  of  how  abstractly  to  define  the  decomposed 
subproblems.  The  approach  to  the  static  decomposition  Is  usually  a  creative 
decision,  based  on  experience  and  not  directed  by  the  methodology;  hence, 
it  needs  positive  management  control.  Decomposition  Is  affected  by  the 
determination  of  which  portions  of  the  problem  solution  can  be  taken  from 
previous  design  work.  The  Implication  is  that  the  system  manager  should 
scan  previous  designs  whose  more  abstract  models  may  be  valuable  as 
starting  points.  If  no  suitable  abstractions  are  discovered,  the  problem  will 
need  to  be  solved  strictly  by  the  unpredictable  creative  activity  of  design. 
However,  if  usable  abstractions  are  found,  the  decision  of  how  to  decompose 
the  original  client's  requirements  may  be  directed  by  the  availability  of  abstract 
models  for  modules  Included  in  a  decomposition.  The  decisions  on 
decomposition  and  activity  of  design  (creative  or  reappllcatlve)  must  be  made 
concurrently  as  a  first  step. 

The  problem  of  finding  predesigned  abstract  models  which  fit  possible 
components  of  the  current  requirements  brings  into  focus  an  ancillary  issue 
which  should  be  noted.  This  Is  the  creation  and  maintenance  of  an 
abstraction/implementatlon  library.  Such  a  library  would  greatly  aid  in  efforts 
to  increase  the  cumulativity  of  software  development.  The  publication  and 
standardization  of  design  abstractions  (especially  very  high  level  ones)  would 
certainly  assist  the  effort  of  creating  an  accumulation  of  abstract  models. 
However,  the  marginal  success  gained  by  the  several  mathematical  libraries 
of  this  type  points  out  three  requirements  for  the  success  of  such  a  library: 
1)  it  must  be  well  structured  and  easily  accessed  (perhaps  automated).  2) 
It  must  be  well  understood  by  Its  users,  and  3)  It  must  be  In  a  common, 
standardized  notation. 

For  large  scale  developments,  the  horizontal 
decomposition/recomposition  process  is  especially  important.  Management 
of  multi-man  designs  requires  that  horizontally  decomposed  modules  must 
be  (made  to  appear)  independent  of  each  other  (decoupled).  In  many 
instances,  it  will  not  be  possible  to  decompose  the  problem  Into  decoupled 
modules  of  an  appropriate  size.  In  such  cases,  the  effects  of  the  coupling 
must  be  abstractly  defined  within  each  module.  This  technique  may  require 
verification  at  recomposition  that  each  coupled  module  acts  (or  interacts)  In 
the  way  it  has  been  abstractly  described  in  each  of  its  coupled  partners. 
That  Is.  at  recomposition  the  abstract  representation(s)  of  a  module  within 


other  modules  must  be  reconciled  with  the  actual  design  for  the  module  to 
produce  a  single  consistent  representation.  Constant  management  attention 
Is  required  on  this  very  critical  problem  of  component  communication. 

The  timing  of  recomposition  is  another  one  of  the  creative  decisions 
that  must  be  developed  through  experience.  For  totally  independent  modules, 
recomposition  Is  necessary  only  at  the  end  of  the  design  process.  However, 
coupled  modules  may  be  recomposed  when  the  advantage  achieved  by 
decomposition  is  outweighed  by  the  necessity  to  share  Information  or  design 
decisions  among  modules.  Also,  intermediate  recompositions  may  be  useful 
to  aid  the  manager's  or  client's  perception  of  the  system.  Recomposition 
is  done  with  the  union  of  abstract  designs  (abstract  machines)  and  their 
underlying  theories.  The  new  larger  abstract  design  combines  the  attributes 
(ie.  invariants,  state  components,  generic  parameter  definitions,  observations, 
and  operations)  of  the  decomposed  abstract  designs  Into  the  smallest  possible 
complete  set  of  attributes.  That  is.  for  example,  identical  state  components 
appearing  In  two  abstract  designs  which  are  recomposed  will  appear  only 
once  in  the  recomposed  machine.  (See  'Shared  Subtheories'  In  [Burstall.80] 
for  a  more  detailed  explanation  ol  combining  theories.) 

b.2  Vertical  decomposition. 

Vertical  decomposition  denotes  the  different  levels  of  design  decisions 
and  simplifications  which  are  documented  in  the  various  steps  (called 
advancements  and  refinements)  of  the  specification  process.  Vertical 
decomposition  might  also  be  called  dynamic  decomposition  because  it  Is  a 
process  which  continues  throughout  the  design  process.  However,  at  each 
successive  level  of  dynamic  decomposition  the  designer  is  obligated  to 
maintain  the  consistency  between  the  new  level  and  the  previous  level  of 
the  design.  This  constant  check  on  the  consistency  of  the  successive  levels 
of  design  removes  any  further  requirement  to  recompose  the  various  vertical 
levels. 

In  the  specification  of  a  software  system,  there  are  two  basic  areas 
of  concern  to  the  software  designer.  The  first  is  the  accurate,  complete, 
and  verifiable  documentation  of  the  system  required  by  the  client.  The  second 
is  a  design  whose  primitives  can  be  easily  and  efficiently  Implemented.  These 
two  concerns  are  each  sufficiently  complex  that  the  combination  of  them  in 
a  design  methodology  results  In  specifications  which  are  often  muddled  and 
incomprehensible.  Our  methodology  structures  the  design  process  so  that 


the  separation  of  these  concerns  is  possible.  This  separation  eases  the 
design  process  and  facilitates  the  implementation  of  the  resultant  design. 
Advancement  records  and  formalizes  the  design  decisions  while  refinement 
simplifies  the  formal  representation  of  the  design. 

Advancement. 

When  the  designer  takes  decisions  to  move  an  abstract  design  closer 
to  the  client's  required  system,  he  restricts  the  different  implementations 
(called  the  family  of  systems)  specified  by  the  abstract  design.  Taking  these 
restricting  decisions  Is  the  embodiment  of  the  creative  craft  of  limitative 
design.  It  is  essential  to  record  decisions  as  precisely  as  possible  so  the 
resulting  system  Is  accountable,  verifiable,  and  maintainable.  We  advance  the 
abstract  design  toward  the  required  system  each  time  a  new  level  of  decisions 
is  taken  and  documented. 

In  many  cases  the  order  In  which  decisions  are  taken  Is  defined  or 
influenced  by  factors  outside  the  control  of  the  software  designer  —  like  client 
requirement  clarification.  Information  Input  from  external  sources,  etc. 
However,  where  possible  the  decisions  documented  by  the  hierarchy  of 
advancement  specifications  should  be  directed  by  the  rule  that  decisions  about 
which  the  designer  (or  client)  is  most  confident  would  be  used  to  advance 
the  specification  first.  This  is  an  obvious  technique  for  limiting  the 
backtracking  required  when  questionable  decisions  need  to  be  rescinded. 
A  second  rule  suggests  that  critical  decisions  should  be  identified,  if  not 
actually  made,  as  early  as  posslble(Parnas,72].  The  order  In  which  decisions 
are  made  is  very  important  but  cannot  be  legislated  —  the  experience  and 
good  judgment  of  the  designer  is  an  important  factor  In  the  proper  ordering 
of  decisions. 

Refinement 

The  second  area  of  concern  to  the  designer  has  less  to  do  with 
creative  art  of  designing  a  system  and  more  to  do  with  Insuring  a  design 
is  not  overly  complex  and  Is  likely  to  be  implementable  on  a  concrete  machine. 
The  following  picture  illustrates  the  difference  between  advancement  and 
refinement  of  a  specification.  (Advancement  by  decisions  A  and  B  restricts 
the  legal  machine  states;  the  refinement  creates  a  new  but  equivalent 
representation  of  the  state  space.) 


ABSTRACT  MACHINE 
STATE  SPACE 


FIG.  11-1  —  Advancement  and  Refinement. 


The  refinement  process  allows  the  specification  of  an  abstract 
machine  to  be  changed  to  an  equivalent  machine  with  a  different 
representation[Jones.80].  In  general,  a  refinement  is  used  to  make  the 
machine  representation  slightly  more  concrete,  although  that  is  not  always 
the  case  —  a  simple  regrouping  of  components  for  clarity  is  another 
refinement  usage.  More  specific  reasons  for  producing  a  refinement  include 
the  following: 

1.  After  several  advancements  of  an  abstract  machine  the  complexity  and 
detail  of  the  state  space  restrictions  often  becomes  unwieldy  and  difficult  to 
understand.  At  such  a  point,  a  refinement  would  be  useful  to  create  a 
machine  where  these  restrictions  are  less  cumbersome  or  are  Implicit  in  the 
structure  of  the  machine.  That  is,  a  new  state  space  equivalent  to  the 
remaining  portion  of  the  old  state  space  is  defined. 

2.  If  new  operations  are  difficult  to  define  on  the  abstract  machine  as  it 
currently  exists  (or  old  operations  have  grown  unwieldy  and  difficult  to 
understand  because  of  past  advancements)  then  is  may  be  possible  to  refine 
the  state  space  to  facilitate  the  specification  of  the  operations. 

3.  Implementation  considerations  might  also  prescribe  the  refinement  of  the 
abstract  machine.  These  considerations  are  often  efficiency  considerations 
in  the  latter  portions  of  the  design  process.  For  example.  If  an  adequate 
replacement  for  the  abstract  machine  exists  which  represents  more  closely 
the  hardware  or  software  features  of  the  intended  (concrete)  machine,  then 
this  new  representation  is  likely  to  be  less  expensive  to  implement  in  terms 
of  design  effort,  system  resource  requirements,  etc. 
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4.  The  Initial  decomposition  of  the  design  was  done  to  structure  the  design 
effort  and  make  It  more  comprehensible  by  separating  the  different  concerns. 
At  some  point,  the  decomposed  modules  will  need  to  be  recomposed  to  form 
the  total  system.  But  before  the  different  modules  can  be  recomposed  Into 
a  single  abstract  machine,  the  components  held  In  common  by  these  modules 
need  to  be  refined  Into  an  Identical  representation  in  all  modules.  This  will 
allow  the  common  machine  components  to  be  represented  by  a  single 
component  of  the  recomposed  machine  state  space. 

From  this  discussion  It  can  be  noted  that  refinement  is  not  a 
framework  for  documenting  design  (as  Is  advancement)  but  is  a  tool  for 
facilitating  the  readability  and  implementabllity  of  the  design  specification. 
The  freedom  to  make  refinement  and  advancement  design  steps  In  any  order 
required  by  the  problem  Is  critical  to  the  generality  of  our  methodology. 
(See  [Domolkl.80]  for  a' very  brief  analysis  of  the  difference  between  the  two 
theory  relations  we  have  called  advancement  and  refinement.) 


b.3  Summary. 

The  hierarchical  nature  of  this  design  methodology  is  a  result  of  the 
I  combination  of  the  two  types  of  decomposition,  vertical  and  horizontal.  The 

following  diagram  will  help  to  demonstrate  this  point. 
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FIG.  11-2  ~  The  Hierarchy 


There  may  be  many  decompositions  (vertical  and  horizontal)  which 
are  wrong  for  a  particular  problem;  there  certainly  Is  not  a  single  one  which 
Is  right.  Indeed,  the  best  decomposition  for  a  problem  may  well  depend  on 
such  factors  as  client's  understanding  of  the  requirements,  the  software 
engineer's  abilities,  available  abstractions,  size  of  problem,  etc.  Horizontal 
decomposition  may  separate  modules  (abstract  subproblems)  which  relate  to 
different  requirements  set  forth  by  the  client.  Or.  It  may  separate  out 
important  parts  of  the  state  space  for  closer  attention.  Vertical  decomposition 
can  order  decisions  together  by  effect,  by  degree  of  difficulty,  or  by  the 
probable  stability  of  the  decisions. 

c.  Formal  Specification. 

in  order  to  unambiguously  state  the  requirements  and  design  of  the 
desired  system,  we  will  use  a  formal  specification  language.  Using  a  formal 
language  allows  us  to  contemplate  design  Issues  and  perform  design 
verification  prior  to  writing  any  program  code. 

We  selected  an  extensible  set  theoretical  notation,  sometimes  referred 
to  as  "Z*.  for  our  formal  specification  notation.  Although  it  is  not  executable, 
it  does  have  the  scope  to  describe  theories  at  any  level  from  the  very  abstract 
to  a  Pascal-like  pseudo  programming  language.  This  notation  is  state  based 
with  parameterized  theories.  In  it  we  have  the  capacity  for  both  procedural 
and  data  abstraction. 

For  a  more  complete  Introduction  to  this  notation  see  [Sufrin.82], 
[Morgan. 82a],  and  [Morgan.82bJ.  A  brief  review  of  relevant  aspects  of  the 
notation  is  presented  in  Appendix  A. 

d.  Verification. 

In  our  methodology,  we  must  have  the  capability  to  formally  and 
informally  verify  the  products  of  the  design  process.  The  informal  verification 
techniques  Include  walkthroughs,  audits,  reviews,  and  program  testing.  Since 
these  are  commonly  found  in  the  literature  (eg.  [Yourdon.78]),  we  will  not 
dwell  on  them  except  to  explain  how  they  are  used  in  conjunction  with  the 
formal  products  of  the  design. 

The  Informal  techniques  can  be  used  to  check  the  formal  design  in 
exactly  the  same  manner  as  would  be  done  in  other  methodologies  to  check 
informal  designs.  Of  course,  the  participants  in  the  review  or  walkthrough 
must  be  conversant  In  the  formal  notation  and  its  semantics  In  order  to  verify 


a  formal  design.  If  part  of  the  design  is  brought  into  question  by  this  Informal 
verification,  then  formal  checks  could  be  instituted  to  clarify  the  parts  in  doubt. 
Such  a  two  level  verification  approach  focuses  the  mathematical  exactness 
of  formal  verification  at  the  critical  points  of  the  design,  thereby  reducing 
its  expense. 

The  informal  techniques  could  also  be  used  whenever  it  is  necessary 
to  compare  the  formal  documentation  with  other  representations  of  the  design. 
For  example,  it  may  be  necessary  to  review  the  formal  design  relative  to 
the  provisional  user's  manual,  to  review  the  program  code  relative  to  the 
formal  design  and  implementation  plan,  or  to  review  the  formal  specification 
relative  to  its  associated  natural  language  explanation. 

We  can  also  use  formal  methods  In  several  ways  to  verify  a  design. 
First,  we  can  prove  the  correctness  of  successive  vertical  levels  of  the  design. 
In  the  limitative  design. -the  allowable  conditions  of  the  system  (states  of  the 
abstract  machine)  must  be  reduced  in  number  or  held  constant  by  each 
successive  vertical  level.  That  Is.  if  S?.  S3>...  represent  successive 
advancements  of  the  state  S.  then  state  space  (S3)  contains  a  subset  of 
states  in  state  space  (Sj).  which  contains  a  subset  of  states  in  (S,) 

(ie.  ...fSj)  c  (Sj)  c  (S1)  c  (S)).  Advancement  is  the  process  of  adding 
restrictions  or  predicates  to  the  state  (le.  S?  =  S1  I  P>.  Refinement  is  the 
process  of  defining  a  new  state  space  representation  which  is  homomorphic 
to  the  previous  state  space.  The  relationship  between  successive  vertical 
decompositions,  whether  related  by  advancement  or  refinement,  can  be 
expressed  by  a  retrieval  function.  (See  [Jones. 80}  for  a  detailed  discussion 
of  retrieval  functions  or,  similarly,  see  [Hoare.72;  Sufrin.81a)  for  a  discussion 
of  abstraction  functions.)  In  advancement,  the  retrieval  function  is  the  identity 
function  restricted  to  a  domain  including  only  the  new  set  of  legal  states. 
The  retrieval  function  in  refinement  embodies  the  homomorphism  relationship. 
With  recomposition,  the  retrieval  functions  can  be  used  to  relate  the  relevant 
parts  of  the  new  state  space  to  each  of  the  component  state  spaces  in  the 
same  manner  as  with  advancement  or  refinement.  In  all  cases,  it  is  possible 
to  demonstrate  if  a  lower  level  design  correctly  models  its  predecessor. 

The  second  method  to  formally  verify  a  design  is  to  state  and  prove 
theorems  about  the  behavior  of  the  abstract  system  and  compare  the  proven 
behavior  with  the  client's  desire.  This  is  the  mode  which  would  be  most 
often  used  to  answer  client  and  management  questions  and  to  clarify  potential 
problems  noted  by  informal  verification  techniques.  Because  of  the 


relationship  which  exists  between  successive  abstract  levels,  we  choose  the 
most  appropriate  design  level  to  determine  the  system  behavior  and  then  are 
confident  that  this  behavior  Is  manifested  In  all  lower  level  machines  unless 
it  is  explicitly  changed  by  a  design  decision.  The  greatest  difficulty  with  formal 
verification  of  this  type  is  that  translating  natural  language  questions  to  formal 
theorems  may  be  a  complex  process  requiring  a  deep  and  detailed 
understanding  of  the  relationship  between  the  formalism  and  reality. 

Finally,  we  can  prove  the  correctness  of  a  program  implementation 
relative  to  its  formal  design.  A  proof  that  the  program  correctly  Implements 
the  requirements  Is  the  ultimate  means  of  demonstrating  reliability.  Although 
substantial  effort  has  gone  into  making  program  verification  a  practical 
technique,  it  is  still  not  viable  on  large  systems  for  two  basic  reasons.  First, 
the  cost  and  complexity  of  formal  program  verification  make  it  economically 
infeasible  on  a  large  -  scale[Berg.82;  Pressman. 821.  Secondly,  program 
verification  assumes  the  appropriateness  of  the  formal  specification:  however, 
as  we  noted  earlier,  there  is  no  formal  way  of  validating  that  the  specifications 
actually  reflect  the  client's  requirements.  Therefore,  a  proven  implementation 
may  be  a  correct  solution  to  the  wrong  problem. 

Because  of  these  two  problems,  we  choose  to  deemphasize  the  role 
of  formal  program  verification  and  reemphasize  the  other  forms  of  verification. 
Additionally,  we  attempt  to  resolve  the  requirement  validation  problem  by 
incremental  requirement  definition  with  client  understanding  and  agreement. 
That  is.  If  the  Initial  design  is  so  simple  that  it  obviously  satisfies  the  client's 
needs  and  if  the  successive  levels  of  design  can  be  proven  (by  retrieval 
functions)  to  accurately  model  that  initial  design,  then  only  the  design  changes 
(advancements)  need  to  be  validated.  Since  these  changes  are  done 
incrementally  with  constant  client  interaction  and  with  properties  of  the  design 
proven  in  the  abstract  machine,  the  likelihood  of  solving  the  right  problem 
will  be  high.  Therefore,  we  have  shifted  the  emphasis  of  our  methodology 
to  the  very  earliest  portion  of  the  lifecycle  —  the  requirements  definition  and 
validation. 

It  Is  the  intent  of  this  methodology  that  formal  verification  will  be 
separated  from  the  design  process  so  that  management  can  control  these 
two  aspects  Independently.  Indeed,  the  formal  verification  will  be  done  by 
someone  other  than  the  designer  (perhaps  a  mathematician)  as  an 
independent  check  of  the  design.  However,  to  be  of  benefit  to  the  designer 
and  the  manager,  all  verification  must  be  accomplished  in  a  timely  manner 
and  coordinated  with  the  designer. 


One  final  point  needs  to  be  made  about  verification  within  this 
methodology:  management  must  control  the  degree  of  verification  applied  to 
individual  modules  of  the  design  and  to  the  system  as  a  whole.  That  is. 
formal  methods  can  be  applied  at  different  degrees  of  rlgor[Jones.80],  as 
can  Informal  methods.  The  manager  must  balance  the  type  and  degree  of 
these  two  forms  of  verification  to  best  suit  the  project.  We  shall  not  attempt 
to  define  a  standard  or  even  a  minimum  level  of  verification  required  for 
all  systems. 

(The  following  are  a  few  of  the  many  possible  references  for  the 
mathematics  of  formal  verification:  [Abrial,82].  [Berg. 82].  [Dahl. 721. 
(Dijkstra.76).  [Qrles.81].  [Hoare.80],  [Jones. 801.  [Richardson. 82].  [Sufrln.81c].) 


11.3  Methodology  Overview 

This  section  will  put  the  software  engineering  concepts  discussed  in 
the  previous  section  into  perspective  by  integrating  them  into  a  complete 
methodology.  The  first  subsection  explains  the  methodology  in  terms  of  the 
products  of  the  design.  As  a  cross-reference,  the  second  subsection  briefly 
outlines  the  methodology  by  defining  the  activities  of  each  design  participant 
during  the  software  lifecycle. 

We  have  divided  the  software  lifecycle  Into  six  phases  for  the  purposes 
of  our  methodology: 

1.  Requirements  definition, 

2.  Problem  decomposition. 

3.  Abstract  design. 

4.  Detailed  design. 

5.  implementation  and  testing, 

6.  Operation  and  maintenance. 

Within  these  phases  we  have  included  three  baselines  and  five  recommended 
product  review  points. 

Baselines  are  part  of  a  management  concept  which  has  been  proven 
In  large  scale  software  development  efforts  —  it  Is  the 
mllestone/basellne/conflQuratlon  management  approach.  Very  briefly,  this 
approach  advocates  setting  incremental  targets  (milestones)  In  resource 
utilization  and  development  completion  which  can  be  compared  against  actual 
results.  As  certain  of  these  targets  are  reached,  selected  products  of  the 


design  (documentation,  client  agreements,  design  steps,  code,  etc.)  are 
verified  and  frozen  (baselined).  They  may  then  be  changed  only  If  approved 
through  the  configuration  management  system. 

A  configuration  management  system  views  the  product  In  design  as 
a  configuration  of  components  (modules).  Before  baselining  the  designer  owns 
a  component;  after  baselining  it  Is  owned  by  management,  who  then  control 
further  changes  to  that  component.  In  this  way.  the  manager  will  always 
be  able  to  determine  the  current  approved  status  (configuration)  of  the  system. 
He  can  also  authorize  independent  audits  or  additional  reviews  to  recertify 
the  configuration.  (Further  details  on  the  topics  of  milestones,  baselines, 
and  configuration  management  can  be  found  in  most  references  on  software 
development  management;  see  especially  [Boehm. 81]  or  [Jensen. 79).) 

The  advantages  of  this  approach  to  the  control  of  the  management 
process,  resource  accountability,  and  product  reliability  are  obvious.  We  are 
convinced  that  such  a  capability  must  be  woven  Into  any  methodology  if  it 
is  to  be  practically  viable.  Because  of  the  incremental  design  technique  of 
our  methodology,  milestones,  baselines  and  a  configuration  management 
system  can  be  integrated  directly  into  the  methodology  to  the  degree  desired 
by  management.  There  are  three  points  of  control,  or  baselines,  which  are 
inherently  part  of  our  methodology  —  the  abstract  design  baseline,  the 
detailed  design  baseline,  and  the  implementation  baseline. 

a.  The  Products. 

Requirement  definition.  The  first  phase  requires  the  definition  of  user 
requirements  In  Informal  text.  This  documentation  must  correctly  reflect  the 
client's  general  needs;  therefore,  the  emphasis  will  be  on  completeness  rather 
than  detail.  A  more  detailed  representation  of  the  client's  requirements,  if 
available,  would  be  useful  to  guide  the  designer  in  later  phases  but  is  not 
necessary  at  this  point. 

Problem  decomposition.  The  first  formal  product  of  the  lifecycle  is 
a  set  of  initial  abstractions,  one  for  each  horizontally  decomposed  module 
of  the  system.  With  each  Initial  abstraction  will  be  an  allocation  of  the 
requirements  which  must  be  satisfied  by  the  following  levels  of  design  for 
that  module.  Other  documents  produced  In  this  phase  include  the  initial 
budget,  the  initial  milestones,  and  the  definition  of  standards. 


At  the  end  of  this  phase  Is  the  first  review  —  the  Decomposition 
Review.  It  will  assess  the  completeness  of  the  requirement  allocation,  the 
suitability  of  the  initial  abstractions,  and  the  degree  of  coupling  among  the 
modules.  As  a  result  of  this  review,  the  designers  should  understand  their 
module's  abstract  starting  point  and  how  their  design  will  interface  into  the 
system  as  a  whole.  The  participants  in  this  review  must  include  all  of  the 
designers,  as  well  as  the  manager  and  client. 

Abstract  design.  The  abstract  design  baseline  occurs  at  the  end  of 
the  design  phase  from  the  problem  decomposition  to  the  point  where  details 
specific  to  the  client's  problem  (rather  than  a  large  class  of  problems)  are 
decided.  The  design  specifications  that  occur  In  the  abstract  design  phase 
are  those  that  might  be  found  In  an  abstraction  library.  Unlike  the  other 
two.  the  timing  of  this  baseline  Is  not  precisely  defined  for  all  modules  but 
is  based  on  the  magnitude  of  the  design  problem. 

The  baselined  products  from  the  abstract  design  include  the  formal 
design  specification,  the  verification  documentation,  the  client  documentation, 
and  resource  management  documentation.  One  part  of  the  client 
documentation  which  Is  baselined  at  this  point  is  the  provisional  user's  manual. 
This  user's  manual  embodies  the  baselined  abstract  design  and  extrapolates 
that  design  to  an  Implementation  based  on  the  designer's  current 
understanding  of  the  requirements.  Naturally,  this  manual  will  not  be  accurate 
In  every  detail  since  most  of  the  detailed  decisions  have  not  been  taken; 
however,  it  is  an  excellent  opportunity  to  compare  the  perception  of  the 
designer  and  the  client,  and  force  the  client  to  begin  to  formulate  the  details 
of  his  requirements.  (Boehm  calls  this  technique  ‘anticipatory  documentation* 
and  suggests  that  it  can  be  highly  effective  in  reducing  lifecycle 
costs(Boehm.81].) 

At  the  end  of  this  phase  but  before  the  documents  are  baselined, 
the  Abstract  Design  Review  is  held.  This  activity  will  review  each  formal 
abstract  design  for; 

-  an  evaluation  of  the  design  approach 

—  likely  requirements  are  still  reachable  in  the  design 

—  the  design  will  lead  to  an  implementabie  system 

~  consistency  with  the  associated  informal  text 

>  compliance  with  standards 

-  an  evaluation  of  the  required  formal  verification. 


Additionally,  this  review  will  establish  the  feasibility  of  the  system  defined  by 
the  provisional  user's  manual.  This  review  is  attended  by  designers,  verifiers, 
the  client,  and  the  manager. 

Detailed  design.  The  design  phase  from  the  abstract  design  baseline 
until  Just  prior  to  implementation  is  called  the  detailed  design  phase,  it  is 
in  this  phase  that  the  experience  and  ability  of  the  software  engineer  pays 
dividends.  The  main  reason  for  this  is  that  design  (especially  detailed)  is 
rather  like  a  funnel,  with  each  design  decision  narrowing  the  working  area. 
Consequently,  the  molecules  (requirements)  attempting  to  make  their  way 
through  the  funnel  begin  to  interact  and  interfere  with  each  other.  Unless 
fruitful  compromises  are  discovered  among  these  molecules,  some  will  be 
thwarted  as  others  take  precedence.  Since  the  specific  requirements  of  a 
system  especially  the  non-functional  requirements  and  Implementation  factors, 
are  never  mutually  exclusive,  the  designer's  difficulties  are  greatly  compounded 
by  this  need  to  seek  compromises  and  trade-offs  among  the  various  factors 
he  must  consider  simultaneously.  There  is  a  tool  which  can  be  used  In 
conjunction  with  this  methodology  which  allows  the  designer  to  evaluate  the 
design  compromises  and  assumptions  he  makes.  This  tool  is  called 
prototyping. 

Prototyping  in  the  context  of  this  design  methodology  is  the  creation 
of  a  model  which  exhibits  the  salient  features  of  the  system  being  examined. 
The  model  may  be  mental,  as  produced  by  the  provisional  user's  manual 
developed  in  the  abstract  design,  or  It  may  be  physical,  like  the  creation 
of  a  display  algorithm  which  Is  executable  on  the  target  machine  and  from 
which  display  characteristics  and  efficiencies  can  be  checked,  in  general, 
we  will  speak  of  prototypes  as  models  which  are  created  in  parallel  with  the 
formal  design  process  and  usually  on  a  smaller  scale  than  a  real 

implementation.  (This  is  the  second  technique,  which  along  with  anticipatory 
documentation,  will  aid  in  the  reduction  of  software  costs  according  to 

(Boehm. 81].  Boehm  calls  extra  products  developed  in  parallel  with  the  early 
design  process  "scaffolding.") 

As  noted  above,  one  of  the  advantages  of  prototyping  is  the  insight 
provided  to  the  designer  concerning  the  appropriateness  of  the  compromises 
he  has  developed  among  the  various  requirements  of  the  system.  A  second 
advantage  accrues  to  the  client  —  the  prototype  gives  him  a  model  of  the 
designer's  system  which  he  can  compare  against  the  system  he  desires. 


One  form  of  prototype  which  can  be  used  in  this  way  is  the  ‘What  If...? 
question.  The  client  presents  a  situation  and  the  designer  determines  exactly 
how  the  abstract  machine  reacts  to  that  situation  by  formally  rephrasing  the 
question  and  defining  the  result  from  the  system  specification.  The  final 
advantage  is  that  prototype  experiments  can  be  used  to  answer  specific 
questions,  such  as:  'Can  our  design  be  limited  by  this  simplification  and  still 
fulfill  the  client's  needs?'  Since  ours  is  a  generally  limitative  methodology, 
the  answers  to  such  questions  are  very  important. 

It  is  conceptually  possible  for  the  detailed  design  to  be  produced  to 
such  a  level  of  detail  that  the  implementation  process  becomes  a  trivial 
rewriting  through  the  use  of  standard  data  structures  and  notational 
transformations.  However.  In  most  instances,  the  verifiability  and  ease  of 
implementation  gained  by  such  a  minute  level  of  detail  is  vastly  overwhelmed 
by  the  cost  of  undertaking  such  an  Intense  design  effort.  The  design  manager 
must  decide  for  each  individual  design  problem  what  balance  of  cost  and 
formal  verifiability  is  most  suitable.  In  other  words,  he  must  determine  when 
the  marginal  utility  of  a  further  level  of  detail  is  too  low  to  warrant  proceeding 
further  in  the  formal  design  process.  In  general,  this  will  mean  taking  a 
few  relatively  large  design  steps  with  another  large  step  to  an  implementation 
in  a  structured  language  (even  If  the  ultimate  implementation  is  not  In  a 
structured  language.)  At  this  point  the  gap  between  the  formal  (verifiable) 
design  and  the  implementation  can  be  bridged  with  the  implementation  notes 
or  by  selection  of  previously  verified  algorithms  from  an  algorithm  library. 
The  implementation  notes  will  include  the  appropriate  Invariants  under  which 
the  algorithms  not  yet  totally  specified  must  function  and  prototype  experiments 
demonstrating  which  algorithm(s)  might  best  satisfy  the  client's  requirements 
in  a  specific  module. 

It  is  during  this  phase  that  the  test  plans  are  developed  for  each 
module  and  the  system  as  a  whole.  The  overall  approach  to  test  planning 
depends  on  the  balance  the  manager  has  struck  between  formal  and  informal 
verification;  however,  informal  testing  against  non-functional  requirements  (eg. 
implementation  speed,  useability,  etc.).  Integration  testing,  and  testing  of 
abstractly  specified  or  unspecified  algorithms  will  always  be  necessary. 

A  test  plan  must  Include  a  definition  of  the  purpose  of  the  test,  the 
method  of  testing  (including  whether  formal  or  informal),  the  inputs  required, 
the  outputs  expected,  and  the  criteria  for  success.  The  outputs  expected 
should  reflect  the  coincidence  of  the  client's  expectations  and  the  behavior 


formally  predicted  from  the  specification.  It  is  important  that  the  test  planning 
be  accomplished  In  conjunction  with  the  design  because  no  one  will  have 
a  better  feel  for  potential  problem  areas  than  the  designer  and  his 
Independent  auditor,  the  verifier. 

The  baselined  products  of  the  detailed  design  phase  include  formal 
specification  documentation  containing  an  abstract  design  to  display  the 
client's  requirements,  a  test  plan.  Implementation  notes  to  guide  the 
Implementation  of  those  portions  of  the  system  which  are  not  immediate  from 
the  formal  specifications,  and  the  latest  verification,  client  and  resource 
management  documentation. 

The  Detailed  Design  Review  assesses  the  detailed  design  with  regard 
to: 

-  the  design  approach 

—  the  order-  and  structure  of  design  decisions  is  appropriate 

—  likely  requirements  changes,  non-functional  requirements,  and 
fine  tuning  can  be  accommodated  in  the  design 

-  consistency  with  the  associated  informal  text 

-  compliance  with  standards 

-  compatibility  with  the  provisional  user's  manual 

-  the  appropriateness  of  the  bottom  level  of  design 

—  state  structure  and  operations  are  appropriate  to  the  hardware 
and  programming  language 

—  step  size  to  the  Implementation  is  appropriate  for  all  algorithms 
This  review  must  also  evaluate  the  completeness  of  the  test 
planning/scheduling  and  the  Implementation  notes  to  be  used  in  the  next 
phase,  it  is  important  that  ail  design  participants.  Including  the  implementors 
and  the  client,  are  involved  in  this  review. 

Implementation  and  testing.  The  implementation  baseline  follows  the 
coding  and  acceptance  verification  of  the  system.  The  products  frozen  here 
include  all  previous  design  documentation,  resource  usage  documentation, 
verification  results,  final  system  documentation  (eg.  user's  manual,  operation 
manual,  maintenance  manual,  etc),  and  the  system  code. 

During  this  phase  the  products  are  reviewed  twice  to  establish  their 
correctness.  The  first  review,  called  the  Software  Verification  Review, 
establishes  that  the  software  is  ready  for  testing.  The  major  task  of  this 
review  is  to  insure  that  the  software  models  the  formal  specification.  For 


small  important  modules  this  can  be  done  formally;  however,  in  general  it 
will  be  done  using  Informal  review  (walkthrough)  techniques.  The  designers, 
verifiers,  and  Implementers  are  the  key  participants  In  the  Software  Verification 
Review. 

The  second  review  of  this  phase  occurs  just  prior  to  the  implemention 
baseline.  The  System  Review  will  establish  that  the  development  products 
are  ready  for  release  to  the  client.  In  this  assessment  the  results  of  the 
system  tests  are  analyzed  and  the  final  user  documentation  is  matched  against 
the  software  and  its  formal  design.  The  client  serves  as  the  approval  authority 
in  this  review.  After  successful  completion  of  this  review,  the  system  and 
its  documentation  Is  handed  over  to  the  client  and  maintenance  personnel. 


REQUIREMENTS  DEFINITION 


PROBLEM  DECOMPOSITION  < - 

-  Horizontal  Decomposition 

-  Design  Style  (creative/cumulative) 

-  Initial  abstractions 

-  initial  Budgeis/Mitestones 


ABSTRACT  BASELINE 

-  Formal  Design  Specification 

-  vertical  decompositions 

♦  advancement 

♦  refinement 

•  horizontal  recompositions 

-  verification  Documentation 

-  lormai 

♦  correctness 

♦  theorems 

-  informal 

♦  walkthroughs 

♦  audits  - 

♦  reviews 


Resource  Management  Documentation 

-  milestone  reviews 

-  accounting  data 

Client  Documentation  d - 

-  progressive  design  reviews 

-  preliminary  user's  manual 


DETAILED  BASELINE 

-  Formal  Design  Specification 

-  vertical  decompositions 

♦  advancement 

♦  refinement 

-  horizontal  recompositions 

•  Verification  Documentation 

-  formal 

♦  correctness 

♦  theorems 

-  informal 

v  walkthroughs 

♦  audits 

♦  reviews 

-  test  plan 


Resource  Management  Documentation 

-  milestone  reviews 
•  accounting  data 

Client  Documentation  d - 

-  progressive  design  reviews 


Implementation  Plan 


IMPLEMENTATION  BASELINE  < 

-  Implementation  Documentation 

-  Test  Results 

-  Final  Oeslgn  Documentation 


OPERATION  AND  MAINTENANCE 


FIG.  11-3  The  Lifecycle  and  the  Development  Products. 


b.  The  Activities. 


This  outline  briefly  defines  the  activity  of  the  design  participants  in 
each  phase  of  the  software  lifecycle.  Those  activities  which  are  preceded 
by  an  asterisk  relate  to  the  formal  aspects  of  the  methodology  and  are 
presented  in  slightly  more  detail. 


Requirements  Definition 

Manager 

1.  Collect  requirements  data  from  the  client  or  systems  analyst. 


Problem  Decomposition 

Manager 

*  1.  Search  the  abstraction  library.  Find  previous  designs  which  might 
be  useful  as  a  component  design  for  the  current  problem. 

*  2.  Decompose  the  requirements.  Identify  and  separate  modules  which 
must  be  creatively  designed  from  those  which  can  use  previous  designs. 

*  3.  Define  initial  abstractions  or  reapplication  starting  points  and 
module  requirements  for  each  module. 

4.  Set  standards: 

*  a.  documentation.  Include  the  standard  for  the  formal 

specification  and  verification  documentation. 

*  b.  vertical  decomposition  granularity  for  each  module.  Define 
the  limits  of  the  vertical  step  size  which  are  appropriate  for  the  problem. 

*  c.  level  of  final  abstract  for  each  module.  Define  the 

approximate  level  of  design  to  be  specified  formally. 

d.  configuration  management. 

a  e.  type/degree  of  verification  for  each  module.  Determine 

if  correctness  verification  is  required  and  at  what  level  of  rigor.  Define  fixed 
review  (walkthrough,  audit)  points  and  criteria  —  including  the  formal 


specification  reviews. 


5.  Develop  initial  budget. 

a.  allocate  resources  to  modules  for  design. 

b.  staff  project/modules. 

6.  Set  initial  milestones. 

7.  Chair  Decomposition  Review. 

Client 

1.  Agree  with  initial  design. 


Designers 

1.  Understand  standards. 

*  2.  Understand  abstract  starting  point  for  their  module(s). 


Abstract  Design 

Designers  (for  each  module) 

*  1.  Vertically  decompose  and  specify  module  through  its  initial  abstract 
steps.  Provide  the  advancement  and  refinement  steps  for  the  module  at  the 
desired  granularity.  Document  each  level  and  emphasize  the  design  decisions 
taken,  their  rationale,  and  alternatives  considered,  and  justify  the  order  of 
decisions  using  the  appropriate  documentation  convention. 

2.  Develop  provisional  user's  manual  for  module. 

Client 

1.  Agree  with  design  decisions. 

2.  Agree  with  provisional  user's  manual(s). 

3.  Ask  "What  if...’  questions. 

Verifiers  (for  each  module) 

*  1.  Do  correctness  verification  of  each  level,  if  required  by  the 
management  standards,  insure  the  correctness  of  the  module  specification 
by  continuous  formal  verification.  This  must  be  done  to  the  degree  of  rigor 
Indicated  by  the  manager.  Results  of  verifications  are  reported  quickly  to 
designer.  Significant  problems  are  reported  to  the  manager. 


*  2.  Prove  theorems  set  by  manager  or  designer.  As  a  result  of 

informal  verification  or  questions  about  the  behavior  of  the  system,  properties 


R 


of  the  system  may  need  to  be  formally  demonstrated. 

*  3.  Fill  In  design  as  required.  The  verifier  may  be  charged  with 
finishing  details  of  the  formal  specification  left  implicit  by  the  designer.  For 
example,  the  verifier  can  do  trivial  promotion  of  operations,  add  explicit 
preconditions  to  operations  as  required  by  advancement,  or  do  substitutions 
and  simplifications  required  by  refinement  since  these  do  not  involve  design 
decisions. 

Manager 

1.  Monitor: 

a.  designer/client  interaction. 

b.  intermediate  resource  usage. 

*  c.  Intermediate  design  progress.  To  monitor  the  design  he 
can  read  the  natural  language  or  formal  documentation  of  the  design 
decisions,  set  up  intermediate  reviews  or  walkthroughs  of  the  design 
(specification),  set  theorems  or  ask  questions  about  the  behavior  of  the 
system,  and  review  the  formal  verification  documentation. 

d.  standards 

e.  milestones 

2.  Direct  integration  of  provisional  user's  manual. 

3.  Authorize  and  budget  the  production  of  prototypes. 

*  4.  Direct  required  horizontal  recomposition.  For  those  modules  which 
must  be  recomposed  prior  to  the  completion  of  their  design,  the  formal 
recomposition  must  be  initiated  and  resources  reallocated  to  reflect  a  new 
design  structure. 

Implementors 

1.  Produce  prototypes  as  required. 


Abstract  Baseline 


Manager 

1 .  Review: 

a.  resource  usage. 

*  b.  design  correctness.  Chair  the  Abstract  Design  Review. 

2.  Redefine: 

a.  milestones. 

b.  resource  allocation  and  budgets. 

3.  Put  appropriate  documents  under  configuration  control. 


Detailed  Design 


Designers  (for  each  module) 

*  1.  Vertically  decompose  and  specify  module  through  its  final  abstract 
stage.  Provide  the  advancement  and  refinement  steps  for  the  module  at  the 
desired  granularity.  Document  each  level  and  emphasize  the  design  decisions 
taken,  their  rationale,  and  alternatives  considered,  and  justify  the  order  of 
decisions  using  the  appropriate  documentation  convention. 

*  2.  Develop  test  plan.  The  test  plan  will  concentrate  effort  on  areas 
left  abstract  in  the  formal  design  and  on  areas  of  complexity  in  the 
specifications.  Test  plans  can  indicate  behavior  predicted  by  the  formal 
design  to  various  test  cases. 

*  3.  Develop  Implementation  plan.  The  Implementation  plan  will  provide 
Insight  to  the  Implementors  about  the  Implementation  of  abstractions  remaining 
in  the  formal  design,  possible  initializations,  and  potential  techniques  for 
accommodating  non-functlonal  requirements. 

Client 

1.  Agree  with  design  decisions. 

2.  Ask  'What  if...*  questions. 

Verifiers  (for  each  module) 

*  1.  Do  correctness  verification  of  each  level.  If  required  by  the 
management  standards,  insure  the  correctness  of  the  module  specification 


by  continuous  formal  verification.  This  must  be  done  to  the  degree  of  rigor 
Indicated  by  the  manager.  Results  of  verifications  are  reported  quickly  to 
designer.  Significant  problems  are  reported  to  the  manager. 

"  2.  Prove  theorems  set  by  manager  or  designer.  As  a  result  of 

informal  verification  or  questions  about  the  behavior  of  the  system,  properties 
of  the  system  may  need  to  be  formally  demonstrated. 

•  3.  Fill  in  design  as  required.  The  verifier  may  be  charged  with 

finishing  details  of  the  formal  specification  left  Implicit  by  the  designer.  For 
example,  the  verifier  can  do  trivial  promotion  of  operations,  add  explicit 

preconditions  to  operations  as  required  by  advancement,  or  do  substitutions 
and  simplifications  required  by  refinement  since  these  do  not  involve  design 
decisions. 

Manager 

1.  Monitor: 

a.  designer/client  interaction. 

b.  intermediate  resource  usage. 

■  c.  intermediate  design  progress.  To  monitor  the  design  he 

can  read  the  natural  language  or  formal  documentation  of  the  design 

decisions,  set  up  intermediate  reviews  or  walkthroughs  of  the  design 

(specification),  set  theorems  or  ask  questions  about  the  behavior  of  the 

system,  and  review  the  formal  verification  documentation. 

d.  standards. 

e.  milestones. 

2.  Direct  Integration  of  module  test  plans  and  develop  the  test 
schedule. 

3.  Direct  integration  of  implementation  plans. 

4.  Authorize  and  budget  the  production  of  prototypes. 

■  5.  Direct  required  horizontal  recomposition.  The  modules  must  be 
recomposed  prior  to  the  completion  of  the  design.  The  formal  recomposition 
must  be  initiated  at  the  appropriate  time. 


Implementors 

1.  Produce  prototypes  as  required. 


Detailed  Baseline 


Manager 

1 .  Review: 

a.  resource  usage. 

*  b.  design  correctness.  Chair  the  Detailed  Design  Review. 

2.  Redefine: 

a.  milestones. 

b.  resource  allocation  and  budgets  (allocate  implementation 

resources). 

3.  Put  appropriate  documents  under  configuration  control. 


'  Implementation  and  Testing 
Implementors  (for  each  module) 

*  1.  Develop  code  according  to  the  formal  specifications  and  the 
implementation  plan. 

Verifiers  (for  each  module) 

1.  Test  according  to  test  plan. 

*  2.  Assess  implementation  anomalies  against  the  behavior  documented 
in  the  formal  design. 

All 

1.  Prepare  final  system  documentation. 

Manager 

1.  Monitor: 

a.  Intermediate  resource  usage. 

b.  intermediate  implementation  progress/test  results. 

c.  standards. 

d.  milestones. 


2.  Oirect  recomposition  of  implementation  modules. 

3.  Authorize  and  budget  production  of  prototypes. 

4.  Chair  the  Software  Verification  Review. 


Implementation  Baseline 


Manager 

1 .  Review: 

a.  resource  usage. 

b.  implementation  correctness.  Chair  the  System  Review. 

2.  Put  appropriate  documents  under  configuration  control. 


Operation  and  Maintenance 


Manager 

1.  Manage  the  transition  to  the  new  system. 

2.  Direct  fine  tuning  and  initial  modification  efforts. 

3.  Evaluate  the  project: 

a.  accuracy  of  resource  estimates. 

*  b,  value  of  initial  abstractions. 

c.  personnel  critique. 

d.  general  lessons  learned. 

*  4.  Direct  updating  of  the  abstraction  library. 


Maintainor 

*  1.  Refer  problems  to  the  formal  specifications.  The  behavior  of  the 

formal  design  will  indicate  how  the  implementation  should  function  and  will 
determine  if  the  problem  is  one  of  implementation  or  design. 

2.  Cost  of  design  adaptation  is  estimated  based  on  resource  data 
attached  to  specification  design  levels. 

3.  Maintain  the  specifications. 


11.4  A  Small  Example. 

A  further  explanation  of  the  proposed  methodology  is  woven  into  the 
very  small  example  development  which  follows.  This  development  is  meant 
to  be  a  gentle  introduction  to  the  style  and  structure  of  the  design  and 
specification  techniques  only.  In  order  to  keep  It  small,  many  of  the  decisions 
have  been  made  for  simplicity  rather  than  for  a  practical  reason.  The  reader 
should  keep  in  mind  that  the  methodology  proposed  In  this  thesis  was 
designed  for  large  scale  system  developments  and,  hence,  it  may  seem 
overbearing  on  such  a  small  example.  For  purposes  of  introduction,  the 
horizontal  and  vertical  decomposition  done  here  will  generate  module 
granularity  which  is  much  smaller  than  is  normally  practical. 

A  management  -tool  which  is  commonly  used  In  the  documentation 
of  a  design  process  is  a  standard  form  or  documentation  template.  The 
exact  format  of  the  template  is  not  nearly  as  significant  as  the  general 
discipline  which  is  imposed  by  Its  use  and  the  management  control  which 
it  allows.  The  template  Is  a  checklist  to  remind  the  designer  of  his  obligations 
in  producing  documentation  and  in  maintenance  of  the  management  defined 
standards  for  the  design.  For  the  manager,  it  differentiates  the  various  design 
steps  to  allow  incremental  control  of  the  formalism,  standards,  and  resource 
utilization. 

Of  course,  any  template  usage  is  complete  only  if  natural  language 
explanatory  text  Is  presented  to  Interpret  the  mathematics.  This  interpretation 
should  be  geared  to  the  future  audience  —  the  design  manager,  the  software 
maintalner.  the  implementer.  and  other  designers.  Although  this  text  is  not 
written  specifically  for  the  client,  it  Is  normal  to  use  these  textual  explanations 
as  the  basis  for  the  user  documentation. 

A  blank  sample  of  the  documentation  template  used  In  this  thesis 
is  presented  on  the  next  page.  The  sections  of  the  template  are  explained 
as  they  are  used  in  the  following  simple  design  example.  Each  use  of  the 
template  represents  a  single  level  of  vertical  decomposition. 


Management  Data: 

Author: 

Date  Started:  Date  Completed: 

Resources  Expended: 

Project  Name: 

Verification  Documentation  Accomplished: 

Client  Documentation  Accomplished: 


Basis: 

Library: 

Prior: 

Forward: 

Comments: 


Requirements/Design  Decisions: 
Auxiliary  Definitions: 

State  (Component)  Definition: 

Observation  Definitions: 

Operation  Definitions: 


FIG.  H-4  —  Design  Template 


Requirements  Definition 

Design  and  implement  a  document  display  system  with  line  editing 
features  for  a  personal  computer.  The  system  will  allow  textual  scrolling, 
plus  simple  user  commands  for  the  creation,  deletion,  and  insertion  of  lines 
of  text. 


Decomposition 

This  problem  decomposes  easily  Into  two  main  modules  —  the 
document  display  and  the  document  editor.  An  appropriate  abstraction  of 
the  document  editor  currently  exists  In  our  expanded  set  theory;  therefore, 
only  the  document  display  module  needs  to  be  creatively  developed.  The 
lower  level  concerns  such  as  hardware,  environment,  system,  and  user 
interfaces  exist  as  components  of  almost  every  system;  therefore,  we  refer 
to  them  as  standard  components.  These  standard  components  need  not  be 
explicitly  defined  in  the  decomposition  step  and  will  commonly  be  recomposed 
in  the  final  levels  of  design.  The  following  figure  represents  the  decomposition 
for  this  simple  problem. 


1.  DISPLAY 

2.  EDITOR 

MODULE 

• 

MOOULE 

T  T 


FIG.  11-5  —  Problem  Decomposition. 


1.  The  Display. 

This  is  the  first  of  our  horizontally  decomposed  problem  components. 

DISPLAY 

(DISPLAY  Is  the  name  of  this  vertically  decomposed  module.) 

Basis: 

Library:  Schema  comblnators 

We  must  look  to  our  specification  library  to  find  the  meaning  of  any 
schema  combinators  which  are  used.  The  remainder  of  the  operators  are 
from  the  standard  extended  set  notation  (*Z“);  these  operators  can  be 
referenced  in  [Abrial.80bl.  [Abrial.82],  and  [Morgan. 82a],  with  a  brief  overview 
in  Appendix  A. 

This  section  will  facilitate  maintenance  of  the  design  by  creating  a 
linked  list  of  the  design  levels. 

Comments: 

This  specification  defines  a  very  simple,  one  document  file,  any  part 
of  which  can  be  displayed  to  the  user.  The  user  can  control  the  parts  of 
the  document  that  he  sees. 

This  section  explains  the  features  included  in  this  level  of  design  and 
relates  this  level  to  the  previous  one. 

Auxiliary  Definitions: 

Here  we  define  any  required  background  mathematics  or  environmental 
attributes  such  as  generic  parameters. 

a.  lines  is  ABSTRACT 

At  this  abstract  level  It  Is  not  important  what  the  exact  nature  of  a 
document  line  will  be.  it  may  be  a  series  of  blanks  and  dots,  a  succession 
of  different  colors  or  hues.  or.  more  simply,  a  sequence  of  alphanumeric 
characters.  Until  we  give  a  specific  definition  to  lines  it  will  be  a  generic 
variable. 


State  Definition: 


We  have  defined  In  this  section  the  schema  representing  the  abstract 
machine  state  space.  The  definition  given  is  based  on  the  background  and 
environmental  attributes  defined  above. 

>  t 

♦ 

D I  SPLAY _ _ 1 _ 

doc  1  :  -**  lines 

displayed  :  PCJfVj) 


The  document  is  a  partial  function  from  line  numbers  to  the  lines 
they  represent.  The  lines  selected  by  the  the  user  are  designated  in 
displayed. 

Observations: 

This  section  gives  us  the  opportunity  to  create  windows  onto  the 
machine  so  that  we  can  look  at  (but  not  affect)  its  various  interesting  parts 
at  any  time  while  it  is  running. 

♦DISPLAY _ 

DISPLAY 

DISPLAY' 


©DISPLAY'  -  ©DISPLAY 


This  is  the  generalized  null  operation  on  which  observations  are  based 
(ie.  the  state  is  not  affected  by  the  observation.)  Henceforth,  this  standard 
♦  schema  will  not  be  explicitly  defined. 


APPEARANC 


♦DISPLAY 

picture'  :  JV1  -**  lines 


picture'  -  doc  P  displayed 


The  user  will  see  that  portion  of  the  document  which  he  has 
designated  to  be  displayed.  Note  that  this  observation  could  also  have  been 
made  a  derived  component  of  our  state  space  and  would  have  been 
automatically  updated  with  each  state  change.  Choosing  to  make  the  user's 
picture  an  observation  forces  us  to  request  a  picture  update  each  time  the 
state  changes  —  and  that  is  more  typical  of  what  actually  happens  In  a  display 
system  implementation. 

Operations: 

Here  we  represent  the  transition  functions  (events)  which  cause  our 
abstract  machine  to  move  between  points  In  the  state  space. 

In  this  module  of  the  specification,  we  are  concerned  with  what  the 
user  sees  of  the  document,  not  in  changing  the  document  itself. 
Consequently,  we  do  not  want  the  state  component  doc  to  be  affected  by 
the  following  operations.  Therefore,  we  adhere  to  the  rule  that  operations 
should  be  defined  on  the  lowest  reasonable  state  component  (in  the  following 
case,  displayed)  and  should  not  be  promoted  to  the  full  state  until 
necessary  to  complete  the  design. 


AD  I  SPLAYED. 


displayed , 
displayed ' , 
lineset 


PW,) 


status 


STATUS 


status ' 


SUCCESS 


This  is  the  delta  (or  change)  operation  which  provides  a  shorthand 
notation  for  our  operation  definitions. 

The  status  output  will  allow  us  to  provide  for  any  error  conditions 
which  may  be  necessary.  Advancement  of  the  design  may  require  us  to 
restrict  the  domain  of  our  machine  operations;  however,  our  machine  must, 
in  the  end.  be  robust  enough  to  allow  all  operations  to  be  attempted  from 
any  element  of  the  machine  state  space.  Hence,  error  results  are  a  required 
aspect  of  our  design.  The  set  of  status  conditions.  STATUS,  is  a  standard 
set  which  cannot  be  fully  specified  until  the  design  is  complete.  SUCCESS 
is  an  abstract  element  of  STATUS  which  signifies  that  the  operation  was 
attempted  from  a  state  which  satisfied  the  operation's  preconditions  and. 
therefore,  that  the  operation  succeeded. 


ADDD I  SPLAY- 


AD  I  SPLAYED 


displayed'  -  displayed  u  lineset 


This  allows  more  lines  to  be  designated  as  visible  to  the  user. 


DELETED I SPLAY _ 

AD I SPLAYED 


displayed'  -  displayed  -  lineset 


DISPLAY  1 

(This  level  of  vertical  decomposition  Is  an  advancement  of  the  previous 
design  level.) 

Basis: 

Library:  Schema  combinators 
Prior:  DISPLAY 

The  abstract  machine  developed  here  will  be  based  on  the  abstract 
machine  developed  in  DISPLAY. 

Comments: 

We  now  make  the  specification  less  abstract  (reduce  the  family  of 
systems  specified)  by  advancing  the  theory.  We  will  require  that  all  legal 
documents  consist  of  lines  whose  line  numbers  are  consecutive. 

Requirements  /  Design  Decisions: 

This  section  informally  enumerates  the  design  decisions  which  will 
be  formally  reflected  In  this  design  level.  All  significant  changes  to  the 
abstract  machine  and  the  rationale  for  these  changes  should  be  stated 
informally  here. 

|[  1 D  The  line  numbers  in  a  document  will  be  consecutive,  beginning  at 
one. 

State  Definition: 

III  D I SPLAY 1  *  DISPLAY  |  doc  €  SEQ[lines] 

The  type  of  the  state  component  doc  is  changed  from  the  general 
partial  function  to  the  sequence  partial  function,  giving  the  consecutive  line 
numbers  that  we  desire. 

Notice  that  the  formalization  of  the  design  decision  is  annotated  by 
the  number  corresponding  to  the  Informal  description  of  that  design  decision. 

The  observation  and  operation  defined  In  DISPLAY  are  implicitly 
updated  by  this  change  to  the  abstract  machine.  In  general,  the  precondition 
required  by  an  advancement  such  as  this  can  be  determined  by  forcing  the 
new  postconditions  back  through  the  operations  and  observations. 


DISPLAY2 


Basis: 

Prior:  DISPLAY1 

Comments: 

We  can  now  make  more  precise  the  arrangement  of  the  document 
lines  as  displayed  to  the  user.  The  picture  a  user  would  most  naturally  desire 
to  see  is  one  which  displays  a  consecutive  area  of  the  document. 

Requirements  /  Oesign  Decisions: 

111  The  area  to  be  displayed  will  be  a  consecutive  area  of  the  document. 

State  Definition: 

D I SPLAY 2 _ 

D I SPLAY 1 


|[1]  (3m, n  :  JV  )  (displayed  *  m..n) 


(This  vertical  decomposition  is  a  refinement  of  the  previous  design.) 


Basts: 

Prior:  DISPLAY2 

Comments: 

Even  at  this  very  abstract  level  it  is  possible  to  Introduce  a  refinement 
which  will  aid  the  understanding  and  perhaps  increase  the  efficiency  of  an 
eventual  implementation.  This  refinement  introduces  the  end  points  for  the 
set  of  consecutive  lines  designated  by  displayed. 

State  Definition: 

DISPLAY2A _ 

DISPLAY 2 

start  :  JV 

stop  :  JV 


displayed  -  start.. stop 


This  definition  of  start  and  stop  allows  us  to  either  show  or  forget 
the  potentially  space-inefficient  component  displayed  —  that  is. 
displayed  has  become  a  derived  component.  Derived  components  can 
be  used  or  ignored  as  required  by  the  implementation. 


2.  The  Editor. 


This  is  the  beginning  of  the  second  horizontally  decomposed 
component  of  the  system,  the  editor. 


EDITOR 

Basis: 

Library:  SEQ  /  Schema  comblnators 
Prior:  DISPLAY  (Auxiliary  Definitions) 

Only  the  auxiliary  definitions  of  DISPLAY  (in  this  case  the  fact  that 
lines  is  abstract)  are  required  as  the  basis  of  this  level;  the  DISPLAY 
abstract  machine  Is  not  used  here. 

Comments: 

This  abstract  specification  represents  the  simplest  possible  editor. 
It  is  a  portion  of  the  operation  set  from  type  SEQ.  For  ease  of  reference, 
the  sequence  editor  is  extracted  from  the  library  and  reproduced  here. 

State  Definition: 


ED  I  TO! 


SEQ[ lines ] 


The  document  is  simply  a  list  of  lines. 


BADSPOT? 


♦EDITOR 


status ' 


STATUS 


8 pot  i  1. . length (doc) 


status '  -  ERROR1 


where  ERROR 1  e  "The  designated  line  does  not  exist 
in  the  file  and  cannot  be  edited.” 


This  is  the  first  Instance  in  our  design  where  an  error  condition  Is 
required.  Error  conditions  will  direct  that  a  status  other  than  SUCCESS 
be  output.  As  a  rule,  we  will  define  the  appropriate  user  error  messages 
as  the  error  conditions  are  specified.  This  Is  done  because  the  designer 
has  a  much  better  perspective  of  the  error  cause  than  the  implementer  and 


will  generate  more  meaningful  error  messages  than  would  be  possible  at 
implementation.  Error  conditions  will  normally  not  result  in  a  change  in  the 
machine  state  but  are  simply  observations  of  the  machine  (null  state 
transitions). 

The  error  condition  presented  here  results  from  an  illegal  line  number 
being  designated  for  the  editing  operation. 


INSERT. 


AEDITOR 

line 


lines 


doc'  -  insert(doc, spot, line) 


This  operation  adds  a  new  line  at  the  selected  spot  and  moves  all 
following  lines  ahead  one  position  in  the  document. 

The  complete  (total  function)  INSERT  operation  requires  the  addition 
of  the  error  condition  BADSPOT?.  Therefore,  the  complete  operation  would 


INSERT  «  INSERT  V  BADSPOT? 


DELETI 


AEDITOR 


doc'  -  delete(doc, spot) 


I 


I 


3.  The  Combined  Module. 


This  level  rejoins  the  two  horizontally  decomposed  modules  just 
designed. 


COMBINED 


Basis: 


Prior:  DISPLAY2A  /  EDITOR 


Comments: 

This  specification  recomposes  the  display  and  editor  modules  and 
completes  the  abstract  design  of  the  system.  This  module  will  be  the  abstract 
design  baseline  and.  therefore,  will  consolidate  the  design  as  it  currently 
exists.  That  means  that  all  observations  and  operations  must  be  explicitly 
promoted  (if  required),  advanced,  and  refined  to  the  current  abstract  machine 
level  so  that  they  can  be  verified. 

Requirements  /  Design  Decisions: 

1 1 J  The  length  of  the  document  must  be  limited. 

Auxiliary  Definitions: 

a.  maxdoc length  €  JV, 

The  document  length  has  an  upper  bound  which  Is  constant  but  has 
not  yet  been  determined. 

State  Definition: 

COMB I NED _ 

DISPLAY 2 A 
EDITOR 


(1]  length (doc)  <  maxdoclength 


which  we  can  expand  to: 

COMBINED 

doc  : 

SEQ[lines] 

start  : 

JV 

stop  : 

JN 

%%% 

derived 

displayed  : 

p(JV 

in 

length(doc)  <  maxdoclength 

displayed  -  start. 

.  stop 

Note  that  the  document  from  the  editor  and  the  document  defined 
in  the  display  module  have  been  merged  in  the  combined  state  space.  This 
can  be  done  quite  simply  because  the  docs  were  both  of  the  same  type 
tie.  SEQ[ lines])  with  no  contradictory  environmental  attributes  (ie.  lines 
was  defined  consistently  in  the  two  cases).  In  addition  to  merging  the  state 
components,  this  new  schema  includes  the  conjoined  axioms  of  the  editor 
and  the  display  modules. 

Observations: 

a.  The  appearance  observation  is  now: 

APPEARANCE _ 

♦COMBINED 

picture'  :  A  -h>  lines 

picture'  -  doc  f  (start. .stop) 


This  observation  has  been  promoted  to  the  new  combined  state  from 
the  DISPLAY  state.  Additionally,  the  derived  component,  displayed,  has 
been  replaced  by  its  meaning,  start.. stop. 


Operations: 


All  previous  operations  are  consolidated  and  produced  as  functions 

of  the  appropriate  state  component: 

ASTART-STOP 

start, 

stop, 

start' , 

stop' 

lineset' 

JV 

:  *>(*/,) 

status ' 

:  STATUS 

status '  - 

SUCCESS 

in  the  first  two  operations,  we  need  only  substitute  for  the  derived 

component  and  use  this  new  delta  function  which  is  equivalent  to  the  previous 

ADISPLAYED. 


a. 


ADDD I SPLAY _ 

ASTART-STOP 


(start' . .stop' )  -  (start. . stop)  u  lineset 


This  is  the  updated  version  of  the  operation  from  the  DISPLAY  module. 
Notice  that  the  decision  to  display  a  consecutive  area  of  the  document 
constrains  the  new  set  of  lines  which  can  be  added  by  this  operation. 


b. 


DELETED I SPLAY _ 

ASTART-STOP 


(start' .. stop' )  -  (start. .stop)  -  lineset 


This  is  the  updated  version  of  the  operation  from  the  DISPLAY  module. 
The  set  of  lines  removed  from  the  display  must  result  in  a  consecutive  display 

area. 


c. 


INSERT _ 

1NSERTED.TOR 


length(doc')  <  maxdoclength 


The  previous  INSERT  definition  had  to  be  given  the  appropriate 
preconditions  to  adhere  to  all  restrictions  set  in  subsequent  advancements 
of  the  machines.  In  this  case  the  precondition  is  designed  to  make  the  state 
transition  preserve  the  document  length  limit. 


DOCTOOLONG  ? _ 

♦EDITOR 

status '  :  STATUS 

length (doc)  -  maxdoclength 
status'  -  ERROR2 

where  ERROR2  a  "The  document  is  already  at  its 
maximum  length." 


This  error  condition  specifies  that  the  document  cannot  be  extended 
beyond  the  maximum  length  which  has  been  set  for  it.  Notice  that  we  have 
not  had  reason  to  promote  the  editing  operations  past  the  EDITOR  abstract 
machine,  so  this  error  specification  is  also  presented  at  the  EDITOR  machine 
level. 

With  this  error  condition,  the  Insert  operation  becomes: 


INSERT  a  INSERT  V  DOCTOOLONG? 


COMBINEDl 


Basis: 

Prior:  COMBINED 

Comments: 

Up  to  this  point  the  design  has  been  very  abstract  with  no  decisions 
made  which  were  specific  to  this  project.  One  of  the  ways  the  design  was 
kept  abstract  was  by  making  it  generic  on  lines.  We  will  now  begin  the 
detailed  design  for  our  specific  problem  by  defining  this  generic  parameter. 

Requirements  /  Design  Decisions: 

1 1 1  Each  line  in  our  document  will  be  composed  of  a  sequence  of 
characters. 

| [2]|  There  must  be  a  limit  on  the  maximum  length  of  a  line. 

|[3]|  We  must  be  able  to  construct  new  lines  for  insertion  into  the  document. 

Auxiliary  Definitions: 

a.  chars  is  ABSTRACT 

We  will  not  yet  define  what  a  character  will  be  in  this  system. 

b.  lines  a  SEQ[chars]  Ill 

Every  line  in  the  document  is  a  list  of  characters. 

c.  maxlinelength  €  iV1 

There  is  a  constant  which  represents  the  maximum  length  of  any  line. 


State  Definition: 


COMB I NED  J _ 

COMBINED 

newline  :  lines 


ff2])  (Vx  :  1. . length (doc) ) 

( length (doc (x ) )  <  maxi in e length) 

|[  2  D  length  (newline)  <  maxlinelength 


This  state  demonstrates  the  first  instance  where  the  design  progresses 
in  a  constructive  rather  than  a  limitative  fashion.  We  have  found  it  necessary 
to  add  a  new  component,  newline,  to  the  abstract  machine.  This  new 
component  represents  a  new  line  which  we  can  add  to  the  document.  All 
lines,  including  the  new  line,  must  adhere  to  the  line  length  restriction. 

Operations: 

a.  1 3  J 

ADD- CHAR _ 

newline, 

newline*  :  SEQ[ chars] 

nextchar  :  chars 

status '  :  STATUS 


length (newline)  <  maxlinelength 
newline'  -  newline  *  <nextchar> 

status'  -  SUCCESS 


This  operation  allows  us  to  add  characters  to  the  end  of  the  new 
line.  In  this  way.  we  can  create  any  sequence  of  allowable  characters  as 
a  line  to  add  to  the  document.  In  order  to  add  this  newly  created  line  to 


LINETOOLONG? _ 

newline, 
newline* 
nextchar 

status '  :  STATUS 

length (newline)  -  maxlinelength 

status  *  -  ERROR3 

where  ERROR3  a  "The  new  line  is  already  at  its 
maximum  length." 

The  error  condition  LINETOOLONG?  is  required  for  possible  attempts 
to  add  an  additional  character  to  a  new  line  which  is  already  the  maximum 
length. 

The  total  operation  becomes: 

ADD-CHAR  a  ADD- CHAR  V  LINETOOLONG? 


SEQ[chars] 

chat 


This  specification  will  add  the  machine  and  environment  interfaces 
to  the  design.  The  decisions  taken  here  are  not  complete  or  realistic  but 
serve  to  reduce  the  complexity  of  the  example. 

Requirements  /  Design  Decisions: 

IH  The  character  set  of  the  target  machine.  LSI-11,  will  be  used. 

12]  The  display  surface  Is  24  lines  of  80  characters  (as  required  by  the 
target  VDU.) 

I3H  In  order  to  avoid  panning,  the  maximum  line  width  should  be  the  same 
as  the  screen  width. 

14]  The  maximum  document  length  is  50  lines  due  to  the  target  machine 
memory  limitations.  (We  will  assume  no  disk  storage  Is  available.) 

]5]  All  modifications  of  the  document  will  be  done  on  line  12  of  the  screen. 
16]  The  user's  display  will  show  as  many  of  the  user  selected  lines  as 
possible  while  ensuring  that  one  of  the  selected  lines  is  displayed  at  the 
action  line  of  the  screen  (line  12). 


Auxiliary  Definitions: 


a.  I1J 
char  a 

n,o,p,q,r,s,t,u,v,w,x,y,z, 

A,B,C,D,E,F,G,H,I,J,K,L,M, 

N,0,P,Q,R,S,T,U,V,W,X,Y,Z, 

1,2, 3, 4,5, 6,7, 8, 9,0, 

! /",£,$»%, fi,7, (,) , — 

t,  |, \,\§,  {,[,  +  , 

The  allowable  character  set  has  been  prescribed  by  the  target 
machine. 

b.  maxlinelength  a  80  ff2,3]| 

screenlength  a  24  ([2] 

The  display  surface  is  fixed  by  the  target  machine. 

c.  maxdoclength  a  50  |[4J 

The  constant  maximum  document  length  has  been  set. 

d.  actionline  a  12 

The  physical  screen  line  In  which  all  document  changes  will  be  done 
has  bden  set  as  twelve. 


COMB I NED 1 

cucsorspot  :  JV 


1 6  I  start  -  1 

stop  -  length (doc) 

IS  &  6J  (doc  *  <>)  => 

cursorspot  £  ( 1. . length(doc) ) 
(doc  -  <>)  =*  (cursorspot  -  0) 


This  new  state  space  "recomposes*  the  previous  state  with  the 
required  standard  components  of  the  machine  or  machine  environment,  in 
this  simpte  case,  only  the  notion  of  a  cursor  position  on  the  document  is 
required:  in  more  complex  systems,  such  components  as  printer  files,  screen 
representations,  main  or  secondary  storage  representations,  keyboards,  etc. 
may  be  required. 

For  this  design,  cursorspot  will  always  point  to  the  document  line 
which  appears  at  line  12  of  the  screen. 

Observations: 


a. 

SCREENOFFSET _ 

((MACHINE 
picture 
screen* 

screen'  -  picture  • 

(shif t(actionline-cursorspot)  f  (1 . . screenlength) ) 


JV  -+*  lines 
JV  -**  lines 


SCREENAPPEARANCE  a  APPEARANCE^^,^  ;  SCREENOFFSET 


This  new  observation  builds  on  the  previous  appearance  observation. 
Now,  given  the  current  machine  state,  we  can  determine  what  tine  of  the 
document  (if  any)  is  visible  on  each  line  of  the  VOU.  This  is  done  by 
restricting  the  previously  defined  picture  to  those  document  lines  which 
will  fit  on  the  24  lines  of  the  screen,  based  on  the  knowledge  that  the 
cursor  spot  line  always  appears  at  line  12  (actionline)  of  the  screen. 

The  observation  APPEARANCE  referenced  in  SCREENAPPEARANCE 
has  been  trivially  promoted  the  the  current  state  as  indicated  by  the  MACHINE 
subscript. 

Operations: 


CURSORMO\ 


cursorspot, 
cursorspot ' 


OUTOPVIEW? 


cur sor spot , 

cursorspot'  :  JV 

amount  :  iNT 

status '  :  STATUS 


(cursorspot  +  amount)  /  (1. . length (doc) ) 
cursorspot'  -  cursorspot 

status '  -  ERR0R4 

where  ERR0R4  a  "The  movement  cannot  be  done  because 
it  would  not  leave*  a  line  visible  at  the  actionspot." 


MACHINE  1 


Basis: 

Library:  Schema  combinators 
Prior:  MACHINE 

Comments: 

This  level  of  specification  will  design  the  actual  user  commands 
required  in  the  system.  These  commands  will  be  based  upon  previously 
designed  state  transition  operations.  This  specification  represents  the  detailed 
design  baseline  and  will  be  the  final  groundwork  for  the  total  system  design. 

Requirements  /  Design  Decisions: 

(11  The  following  user  commands  will  be  allowed: 

a.  insert  a  line 

b.  add  a  line 

c.  delete  a  line 

d.  scroll  up  one  line 

e.  scroll  down  one  line 

f.  create  a  line  with  which  to  update  the  document 

State  Definition: 

Unchanged  from  MACHINE. 

Observations: 

Unchanged  from  MACHINE. 

Operations: 

{11  All  user  required  commands  must  be  promoted  to  the  MACHINE  state 
space  and  must  be  made  total  functions  with  the  addition  of  the  necessary 
error  conditions. 


INSERT. 


The  add  a  line  operation  appends  the  new  line  to  the  end  of  the 
document.  The  newline  component  is  then  cleared  for  reuse.  The  newly 
added  line  will  be  shown  at  the  actionline  of  the  screen. 


This  operation  can  be  used  to  scroll  the  screen  any  amount,  either 
up  or  down.  In  order  to  specify  the  required  user  commands  we  limit  the 
scrolling  to  one  line  up  or  down. 


SCROLLUP  «  SCROLL  [amount/-l] 

SCROLLDN  a  SCROLL  [amount/1] 

e.  ADD-CHAR  a  ADD-CHAR^^g 

The  new  version  of  ADD-CHAR  does  not  affect  any  of  the  state 
components  except  as  specified  In  the  original  version  of  the  operation. 
Therefore,  the  operation  Is  trivially  promoted  to  the  current  state  as  denoted 
by  the  MACHINE  subscript, 
such  as  this  one. 

Although  initially  specified,  the  user  view  changing  operations 
ADDDISPLAY  and  DELETED  I  SPLAY  have  not  been  promoted  since 
subsequent  user  requirement  clarification  has  removed  the  need  for  them. 
By  leaving  these  two  operations  In  the  abstract  design  documentation,  we 
have  provided  a  head  start  tor  likely  future  system  adaptations. 


5.  The  System  Module 

This  level  recomposes  the  designed  machine  into  the  remaining 
aspects  of  the  complete  system  design. 


SYSTEM 


Basis: 

Library:  Schema  combinators 
Prior:  MACHINE  1 

Comments: 

In  this  specification,  the  abstract  machine  will  be  placed  into  the 
user's  system  to  complete  the  design.  In  this  simple  case,  no  changes  will 
be  required  In  the  state  space  but  several  new  observations  and  operations 
are  required. 

Auxiliary  Definitions: 

a.  possiblekeys  is  ABSTRACT 

We  will  not  need  to  explicitly  define  all  of  the  keystrokes  that  are 
possible  on  our  target  machine. 


b.  legalkeys  a 


chars  u  {scrollup, 
scrolldn, 
insert, 
add , 
delete, 
quit} 


legalkeys  c  possiblekeys 

The  keystrokes  allowed  by  our  system  are  explicitly  defined  and  are 
a  subset  of  all  possible  keystrokes.  Any  keystroke  not  In  the  set  of  legal 
keys  will  be  an  error. 


,3* 

The  system  user  is  specified  as  an  abstract  relation.  Such  a  view 
of  the  user  does  not  prejudice  the  system  against  unlikely  (but  nonetheless 
possible)  user  inputs. 


BADKEY?. 


♦MACHINE 

key’ 

status ' 


poss iblekeys 


STATUS 


-O 


key'  i  legalkeys 


status '  -  ERRORS 


where  ERRORS  a  "The  input  command  is  not  valid  in 
this  system." 


A  If  the  user  inputs  an  illegal  key  command,  this  error  condition  would  udfc 

;  result. 


USER  *  L00P(BADKEY?) ;  USER 


The  total  definition  of  the  user  requires  that  a  legal  keystroke  should 
ultimately  result  or  the  system  would  never  do  anything  (else)  useful. 

Operations: 

a.  SESSION  a  INITIALIZE;  EXECUTE;  TERMINATE 

The  running  of  a  non-contlnuous  (Ie.  terminating)  system  is  called 
a  session  of  the  system.  We  normally  specify  'hat  a  session  Is  composed 
of  three  phases  —  Initialization,  execution,  and  termination. 

b. 

INITIALIZE _ 

MACHINE' 


doc'  -  <> 
newline'  -  <> 
cuzaorspot'  -  0 


The  abstract  machine  initialization  must  produce  a  legal  machine  state 
for  the  remainder  of  the  design  to  be  consistent.  In  more  sophisticated 
systems,  part  of  the  machine  initialization  values  may  come  from  the 
environment  (eg.  disk  files,  database,  etc.)  which  exists  between  sessions.  For 
this  system,  we  have  designated  a  starting  state  with  an  empty  document. 

c.  EXECUTE  a  SCREENAPPEARANCE ;  USER; 

LOOP  (OPERATE;  SCREENAPPEARANCE;  USER) 

Executing  the  system  requires  that:  1)  the  screen  picture  be  shown 
to  the  user,  2)  the  user  select  a  legal  system  command.  3)  the  system 
transform  the  state  according  the  appropriate  state  operations,  and  4)  the 
system  Iterate  the  previous  three  requirements  until  termination.  The  fourth 
requirement  is  the  responsibility  of  the  OPERATE  operation. 


OPE RATI 


A MACHINE 


key  i*  quit 


legalkeys 


(key  e  char)  =*►  ADD-CHAR  [nextchar/key] 
(key  -  scrollup)  =>  SCROLLUP 
(key  -  scrolldn)  =>  SCROLLDN 
(key  -  insert)  =»  INSERT 
(key  -  add)  =>  ADD 

(key  -  delete)  =»  DELETE 


This  operation  represents  the  driver  module  of  the  implemented 

.  *-■ 

system.  It  will  execute  any  legal  series  Of  user  commands  and  terminate 
the  session  when  so  directed  by  the  user.  Mutual  recursion  between  the 
OPERATE  and  EXECUTE  operations  provides  the  iteration  that  was  noted  in 
requirement  four  of  the  previous  paragraph. 

e.  TERMINATE  a  MACHINE 


The  terminate  operation  will  normally  define  the  allowable  criteria  for 
termination  —  that  Is.  It  will  specify  the  machine  states  In  which  termination 
may  (or  will)  occur.  The  terminate  operation  will  also  define  which  portions 
of  the  machine  state  will  continue  to  exist  (in  the  environment)  between 
sessions. 

In  this  simple  system,  termination  may  occur  In  any  legal  machine 
state  and  the  system  is  entirely  destroyed  at  the  end  of  each  session. 


Although  we  do  not  intend  to  pursue  this  small  example  of  the 
methodology  to  an  Implementation,  It  should  be  obvious  at  this  point  the 
aspects  of  the  design  which  still  must  be  decided  prior  to  an  Implementation. 
For  example: 

1.  how  are  errors  displayed? 

2.  what  Is  the  screen  display  algorithm? 

3.  how  and  where  Is  the  cursor  to  be  displayed? 

4.  how  is  the  new  line  to  be  displayed? 

5.  what  is  the  relationship  between  physical  and  logical  keys? 
...physical  and  logical  screen? 

6.  which  programming  language  is  to  be  used  and  (as  a  consequence 
of  that  decision)  what  will  be  the  implementation  structure  of  the  document? 

These  are  the  types  of  decisions  (eg.  algorithms,  user  interfacing, 
non-functional  requirements,  etc.)  which  are  discussed  in  the  Implementation 


CHAPTER  III 


A  Family  of  Visible  Filing  Systems 

Prior  to  applying  our  proposed  software  design  methodology  to  the 
development  of  an  information  sharing,  windowing  screen  editor  we  will  present 
the  design  for  a  family  of  visible  filing  systems.  This  abstract  design  is  typical 
of  an  entry  in  our  proposed  library  of  high  level  design  abstractions.  This 
high  level  design  will  help  us  intelligently  decompose  and  plan  the  design 
strategy  for  the  case  study  which  follows  in  Chapters  IV  and  V. 

111.1  Introduction. 

Computers  are  commonly  used  to  store  documentary  information,  any 
part  of  which  can  be  made  visible  on  a  CRT  screen  or  printing  device. 
The  software  system  which  provides  this  information  display  Is  called  a  visible 
filing  system.  Some  systems  also  allow  the  viewing  screen  to  be  partitioned 
so  that  various  documents  can  be  made  visible  In  any  desired  arrangement 
on  the  screen.  Such  a  system  Is  called  a  windowed  screen  display  manager. 
Other  systems  allow  information  (figures,  text,  etc.)  to  be  shared  between 
documents  In  a  convenient  and  manageable  manner.  These  systems  are 
called  Information  sharing  filing  systems.  The  systems  we  are  going  to  specify 
here  are  information  sharing,  windowed,  visible  filing  systems. 

This  family  of  display  and  filing  systems  is  an  Important  one  to  define 
in  a  reusable  and  consistent  manner  because  it  has  a  very  wide  applicability 
but  is  not  yet  totally  understood  or  exploited.  As  [Meyrowitz.81]  puts  It: 

•The  window  manager  is  an  emerging  computing  paradigm  which  allows  the 
user  to  create  multiple  terminals  on  the  same  viewing  surface  and  to  display 
and  act  upon  these  simultaneous  processes  without  loss  of  context....  Most 
[current]  implementations  and  their  associated  designs  are  not  readily 
available  for  common  use;  extensibility  is  minimal.* 

Several  attempts  have  been  made  at  defining  such  a  system: 
[Carlson.  82;  Guttag,82;  Hoare.81;  Horning, 79;  Mallgren,82;  Meyer.  82; 
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Meyrowitz.81;  Richardson,81;  Sorensen].  Many  of  these  are  too  concretely 
specified  to  be  reusable  or  extendable  to  other  design  efforts.  Few  allow 
information  sharing  between  documents  —  an  important  aspect  of  our  system. 
The  development  presented  here  is  based  upon  [Hoare  81:  Richardson. 81]  and 
represents  a  very  flexible  family  of  windowed  filers  with  information  sharing 
and  (potentially)  graphical  capabilities. 


111.2  Synopsis. 

Sharing  information  between  documents  one  has  created  and  stored 
is  a  very  useful  but  potentially  very  complex  concept.  The  main  advantage 
of  sharing  information  is  that  a  document  change  can  be  propagated  to  every 
other  occurrence  of  the  shared  information.  On  certain  document  areas, 
which  we  will  call  the  masters,  the  information  has  been  printed  and  can 
be  seen  immediately.  Other  documents  areas,  called  the  slaves,  contain  only 
references  to  the  Information  on  the  master  document  areas.  These 
references  must  specify  where  the  Information  is  to  appear  in  the  slave  area 
as  well  as  what  information  is  to  appear  there.  Of  course,  the  information 
appears  in  the  proper  position  of  a  slave  document  area  only  if  we  look  up 
the  referenced  information  on  the  master  area.  This  type  of  referencing  is 
commonly  done  in  books:  for  example,  with  footnotes  specifying  where  the 
master  material  is  to  be  found  and  a  special  symbol  (eg.  a  footnote  number) 
marking  the  spot  where  the  shared  information  should  appear  (after  look  up) 
in  the  text. 

s 

THE  FUU  RANGE  OF  SOFTWARE  ENGINEERING  PROBLEMS*  EACH  FIGURE  MUST 


+»  Bwwrz.aQ.Mca  20-23,  for  thi  complete  list  of  problems. 


FIG.  Ill-l 


A  Reference. 


Before  discussing  further  the  concept  of  information  sharing,  it  Is 
necessary  to  define  how  we  represent  the  Information  In  our  system.  Consider 
a  filing  cabinet  containing  many  large  sheets  of  colored  paper.  Each  sheet 
of  paper  Is  a  document  and  is  given  a  unique  name.  On  each  of  these 
documents  Is  a  coordinate  grid  so  that  the  location  of  every  speck  of 
information  on  each  document  can  be  Identified  by  a  coordinate.  In  other 
words,  a  reference  to  the  filing  cabinet  with  any  coordinate  location  on  a 
specific  document  should  show  us  what  speck  of  information  appears  there. 
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COORDINATE  GRID 


DOCA(12,2KE' 


FIG.  111-2  —  The  Filing  Cabinet. 


Of  course,  we  should  be  able  to  find  the  appearance  at  each 
document  coordinate  of  our  filing  cabinet  and  It  should  not  matter  whether 
a  reference  to  shared  Information  defines  the  appearance  or  if  the  appearance 
is  Immediately  available.  Therefore,  we  need  a  technique  for  looking  up  a 
reference  one  if  the  coordinate  we  wish  the  appearance  of  is  a  slave.  The 
technique  used  is  called  a  protection.  A  protection  is  a  function  which 
specifies  a  master  coordinate  for  each  point  in  a  slave.  The  appearance 
of  any  coordinate  which  Is  sharing  Information  with  a  master  coordinate  must 
be  the  appearance  of  that  master  coordinate;  that  explains  how  changes  to 
shared  information  are  propogated  to  all  slaves. 


DOCUMENT  A 


MASTER 

AREA 


SLAVE  AREA 


TO  HND  APf  EARANCE  AT  ANY  POINT 
NSW  FOLLOW  PROJECTION  TO  THE 

appdopmaie  point  n  the  master 


FIG.  Ill— 3  —  Projections. 


So  far.  the  system  is  simply  a  filing  cabinet  which  contains  all  of 
the  information  we  have  created  and  stored,  and  a  projection  to  act  as  look 
up  instructions  if  there  Is  shared  Information  In  one  of  our  documents.  But 
what  If  we  need  several  different  look  up  instructions  for  different  information 
sharing  activities?  Certainly,  there  Is  nothing  to  prevent  us  from  having 
numerous  projections.  P,,  P2,  P3,  Pr,  for  all  of  the  different 

slave/master  sharing  arrangements  we  require  In  the  filing  cabinet.  The  only 
complication  arises  when  two  or  more  of  these  projections  provide  look  up 
Instructions  for  a  particular  coordinate  —  which  Instructions  should  be  heeded 
In  that  case?  The  solution  is  to  list  the  projections  In  order  of  precedence 
so  that  it  will  be  obvious  which  projection  Instruction  must  be  followed  If  there 
is  a  choice.  For  example,  with  the  list  of  projections  <P  ,  p  ,  p  ,  p  , 
P_,  ...  >,  and  If  a  coordinate  location  appears  in  the  slave  of  both  P 


and  P..  then  P.  is  the  look  up  instruction  which  will  be  used  for  that  location 
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since  it  appears  later  in  the  list. 

How,  then,  do  we  maintain  the  precedence  relationship  we  have 
developed  in  the  projection  list  and  still  produce  the  single  projection  needed 
as  a  look  up  instruction  to  find  the  Information  appearing  at  any  point  in 
the  filing  cabinet.  The  answer  is  to  flatten  the  list  of  projections  so  that 
only  the  look  up  instructions  prescribed  by  the  projection  with  the  greatest 
precedence  Is  included  for  each  coordinate.  It  should  be  noted  that  reordering 
of  the  projection  list  may  significantly  change  this  flattened  projection  and, 
therefore,  the  appearance  of  the  entire  filing  cabinet. 


rsruecTtON  usr-  <r,,  Pj,  ?3> 


FIG.  111-4  —  Flattened  Projection  List. 


But  there  still  may  be  a  problem  —  if  the  master  of  a  projection 
is  also  the  slave  of  a  projection  in  the  list,  then  a  single  application  of  the 
flattened  projection  will  not  give  us  the  appearance  we  desire.  That  is,  if 
in  looking  up  one  reference  we  find  a  further  reference,  then  we  must  also 
have  look  up  instructions  for  that  second  reference. 


FIG.  111-5  —  A  Projection  Network. 


This  time  the  solution  to  our  problem  is  to  apply  the  flattened  look 
up  instructions  the  exact  number  of  times  required  for  the  coordinate  whose 
appearance  is  desired.  So.  with  our  filing  cabinet  full  of  information  and  with 
that  information  being  shared  In  any  desired  arrangement,  we  are  able  to 
find  the  appearance  of  any  point  on  any  document  in  the  filing  cabinet. 
The  only  useful  capability  which  we  do  not  now  have  is  changing  the 
appearance  of  information  as  it  is  being  shared.  For  example,  it  might  be 
useful  to  italicize  information  that  is  shared  from  another  document  to  show 
that  It  is  not  original  Information.  This  can  be  done  quite  easily  with  a  filter. 
A  filter  will  replace  any  possible  speck  appearance  with  a  desired  new 
appearance  according  to  the  user's  orders.  Each  slave  in  the  flattened 
projection  can  be  viewed  through  Its  own  filter  so  that  any  shared  Information 
will  appeared  altered  as  appropriate. 

Two  final  points  should  be  noted  here.  First,  there  Is  the  possibility 
that  the  projection  network  will  result  in  a  infinite  series  of  look  up  instructions 
for  certain  coordinates  (eg.  when  two  documents  share  information  mutually 
between  themselves).  When  this  happens,  there  is  no  true  master  and  the 
appearance  of  these  coordinates  Is  undefined  just  as  you  would  expect  them 
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FIG.  Ill— 6  —  Undefined  Appearance. 


The  second  point  to  be  made  is  that  it  is  possible  to  change  the 
size  or  shape  of  the  shared  information  by  having  the  projection  cause  scaling 
or  skewing  of  the  information. 


ORIGINAL 


ORIGINAL 

X! 


/' 

ORIGIN 


/* 

ORIGIN 


SCALE  >(4,2) 


SCALE  >0,3) 


SCAUNG 


SKEWING 


FIG.  HI-7  —  Scaling  or  Skewing. 


We  can  now  summarize  the  information  sharing  aspects  of  the  filing 
system.  A  piece  of  information  which  is  shared  among  documents  actually 
only  exists  in  one  place,  called  the  master.  All  other  documents  which  share 


this  information  (slaves)  have  only  a  reference  back  to  the  master  document. 
This  reference  is  in  the  form  of  a  projection  which  defines  the  relationship 
between  the  master  area  and  the  slave  area.  The  relationship  may  be  a 
straightforward  sharing  of  the  unadulterated  information  or  may  include  some 
complex  scaling  to  change  the  size,  shape,  and  appearance  of  the  information 
for  the  stave.  Moreover,  the  relationship  of  the  master  and  the  slave  (by 
way  of  the  projection)  may  even  involve  the  selective  but  consistent 
modification  of  the  content  of  the  shared  Information  by  placing  filters  on 
the  projection.  Obviously,  any  change  to  a  master  area  results  In  an 
equivalent  change  to  all  of  its  slave  areas. 

Basic  to  a  windowed  display  system  is  the  capability  to  position  parts 
of  various  documents  In  any  arrangement  on  the  screen.  However,  this  is 
just  another  form  of  the  problem  of  Infomation  sharing  between  documents 
and  is  solved  with  the  same  mechanism  —  a  projection.  The  stave  area 
of  this  projection  will  always  be  the  screen,  while  the  master  area  will  be 
in  the  filing  cabinet.  Of  course,  the  viewing  system  can  display  only  that 
which  the  filing  system  has  stored. 


Because  this  model  is  the  basis  for  a  family  of  filing/viewing  systems, 
the  emphasis  will  be  on  generality  above  other  considerations:  consequently, 
almost  all  design  decisions  will  be  postponed  to  later  levels  of  specification. 
For  example,  one  member  of  this  family  of  systems  might  produce  documents 
entirely  from  projections  of  basic,  character  documents  (ie.  letters,  numerals, 
etc.)  onto  blank  pieces  of  paper;  while  other  members  might  allow  characters 
to  actually  be  typed  onto  the  pieces  of  paper.  As  a  further  example,  one 
member  of  the  family  may  require  what  is  seen  on  the  screen  to  come  from 
a  single  ‘viewing*  document  in  the  filing  system,  while  some  others  may  allow 
the  screen  to  have  the  selection  of  all  documents  with  which  to  share 
Information. 


111.3  Specification. 


FILER  1 


Basis: 

Forward:  FILING  CABINET1.1  /  PROJSET1.2  /  DISPLAY1.3 

Comments: 

This  specification  represents  a  windowed,  information  sharing  visible 
filing  system. 

(The  FILER  specification  is  adjourned  so  that  the  FILER  components: 
FILING  CABINET.  PROJSET.  and  DISPLAY,  can  be  specified.  This  brief 
Introduction  to  FILER  indicates  the  hierarchical  nature  of  this  module 
specification.) 


FIUNG  CABINET!.  1 


Comments: 

The  FILING  CABINET  models  the  set  of  user  documents  which  contain 
all  the  information  stored  and  displayed  in  the  system.  Each  document  is 
separate  and  distinguishable  from  all  other  documents  and  Is  allowed  its  own 
color  of  paper. 

Auxiliary  Definitions: 

a.  speck  is  ABSTRACT 

b.  coordinate  is  ABSTRACT 

In  the  interest  of  generality,  the  two  basic  concepts  speck  and 
coordinate  are  left  only  informally  defined:  a  coordinate  is  a  point  in  space 
at  which  a  speck  is  visible.  For  example,  on  the  surface  of  a  flat  screen, 
a  coordinate  could  be  defined  by  a  pair  of  real  numbers  x  and  y.  where 
x  measures  the  distance  from  the  top  of  the  screen  and  y  measures  the 
distance  from  the  left  edge.  On  a  simple  screen,  the  speck  may  be  just 
one  of  the  two  values  black  or  white.  On  a  color  screen,  it  may  be  a  triple 
of  real  numbers  (r.g.v)  Indicating  the  intensity  of  the  co'ors  red.  green,  and 
violet.  On  a  document  containing  only  text,  a  coordinate  might  be  a  pair 
of  Integers  (l.c)  giving  a  line  number  and  column  number,  and  a  speck  might 
be  one  of  a  limited  range  of  characters  that  could  appear  in  any  line  and 
column  of  the  document. 

c.  surface  a  coordinate  speck 

A  surface  Is  defined  by  giving  the  speck  which  appears  at  each 
coordinate  of  the  surface  The  domain  of  the  function  gives  the  extent  of 
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the  surface.  For  example,  the  surface  of  a  CRT  screen  may  extend  ovar  all 
x  and  y  coordinates  In  the  range  -1  to  1.  and  at  each  of  these  points,  the 
illumination  is  defined  by  the  corresponding  speck.  A  pictorial  document  Is 
likely  to  have  a  very  large  domain  since  specks  at  many  different  points  will 
be  required  to  define  even  a  simple  figure.  On  the  other  hand,  a  textual 
document,  which  could  be  defined  as  a  mapping  from  coordinates  to  the 
letters  which  occupy  each  row  and  column,  will  likely  have  a  smaller,  simpler 
domain.  Any  surface  defined  In  the  state  space  could  have  an  infinite  domain. 

d.  docname  is  ABSTRACT 

Again  in  the  interest  of  generality,  the  set  of  names  used  for  the 
documents  In  the  filing  cabinet  Is  left  undefined.  The  only  requirement  Is 
that  document  names  be  unique. 

State  Component  Definition: 

FILING  CAB INETl .  ] _ 

documents  :  docname  -+*  surface 

colors  :  docname  -**  speck 

filecolor  :  speck 


dom  (documents)  -  dom  (colors) 


This  formal  definition  says  that  the  FILING  CABINET  consists  of 
of  surfaces  (informally  called  documents)  each  of  which  can  be  accessed 
by  its  unique  name.  These  documents  each  have  a  specific  color  of  paper 
on  which  the  Information  is  presented.  Finally,  the  part  of  the  filing  cabinet 
not  filled  with  documents  has  a  color  of  Its  own. 

The  selection  of  documents  which  exist  In  the  filing  cabinet  Is: 

dom  (documents) . 


> . 


The  extent  (size  and  shape)  of  a  document  listed  In  the  selection  of  documents 
which  has  the  name  dn  is: 
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while  the  content  of  that  document  is: 

ran  (documents  (dn)). 

The  appearance  at  a  coordinate  c  on  this  document  dn  is: 
documents  (dn)  (c). 

(Later  we  will  define  the  appearance  of  any  coordinate  outside  the  extent 
of  document  dn  but  on  the  document's  colored  paper  to  be  determined  by 
colors  (dn) .  For  a  document  name  which  is  not  In  the  index  of  documents 
and  hence  not  in  the  filing  cabinet  (dn  i  dom  (documents)),  the 
appearance  of  any  coordinate  will  be  the  filing  cabinet  color,  filecolor. 

Operations: 

The  following  operations  on  the  FILING  CABINET  allow  the  addition  or 
deletion  of  a  document  or  the  changing  of  a  background  color.  These 
operations  have  been  kept  abstract  by  not  specifying,  for  example,  how  the 
new  document  is  actually  created. 

a. 

ADD-DOCUMENT _ 

AFILING  CABINET1. 1 


dn 

docname 

sf 

surface 

sp 

speck 

dn  /  dom  (documents) 
documents'  -  documents  u  (dn  |— *  sf) 
colors'  -  colors  u  (dn  I-*  sp) 
filecolor'  -  filecolor 


Given  a  new  document.  Its  unique  name,  and  the  color  of  paper  on 
which  It  Is  to  appear,  the  filing  cabinet  is  updated  with  this  new  information 
by  ADD-DOCUMENT. 


AFILING  CAB  I NET 1 . 1 
dn  : 


docname 


documents'  -  documents  \  {dn} 
colors'  -  colors  \  {dn} 
fllecolor'  -  filecolor 


Any  document  and  Its  associated  paper  color  can  be  deleted  from 
the  filing  cabinet  by  supplying  the  name  of  the  document  to  be  deleted. 


c. 


COLOR-CHANGE _ 

AFILING  CABINET1.1 
dn  :  docname 

f  :  speck  —*  speck 


dn  e  dom  (colors) 
documents '  *  documents 

colors'  -  colors  •  {dn  |—»  f  (colors  (dn))} 
filecolor'  -  filecolor 


P I LECOLOR- CHANGE _ 

API LING  CAB  I NET 1 . 1 
f  :  speck 


documents '  -  documents 
colors'  -  colors 


f ilecolor ' 


f  (f ilecolor) 


PR0JSET1.2 


Basis: 

Prior:  FILING  CABINET!. 1  (Auxiliary  definitions) 

Comments: 

The  PROJSET  models  the  interactions  or  sharing  of  information 
between  documents  in. the  FILING  CABINET.  The  sharing  is  done  by 
projecting  one  area  (the  master)  onto  another  (the  slave).  The  order  of  the 
projections  is  significant  because  it  is  used  to  determine  the  result  where 
several  masters  have  projected  into  the  same  slave  area  (projection  overlap). 
Projections  can  scale  or  skew  information  so  that  the  size,  shape,  or 
appearance  of  a  document  part  can  be  changed  as  it  is  being  shared.  The 
information  being  projected  can  also  be  filtered.  The  filtration  is  done  on 
the  slave  end  of  the  projection  and  changes  the  content  of  the  area  being 
projected. 

Projections  will  also  be  used  to  share  Information  between  the  filing 
cabinet  and  the  screen,  thereby  providing  the  capability  to  define  a  windowed 
display  system. 

Notice  that  projections  are  defined  in  what  at  first  glance  may  seem 
to  be  a  backward  fashion  (from  slave  to  master).  The  reason  for  this  form 
of  projection  specification  becomes  clear  when  you  realize  that  the  important 
requirement  will  be  to  determine  the  speck  which  appears  at  a  given 
coordinate.  It  will  seldom  be  necessary  to  ask  at  which  coordinate  a  speck 
will  appear. 

Auxiliary  Definitions: 

a.  filter  •  speck  — *  speck 

The  filter  is  used  to  change  the  specks  on  a  surface  (eg.  exchanging 


red  and  green,  or  changing  characters  to  reverse  video.)  Notice  that  the 
filter  is  a  total  function  on  speck. 


docname 

coordinate 


coord 


This  definition  allows  the  document  name  to  be  used  as  a  component 
of  the  coordinate  in  an  expanded  coordinate  system.  That  is.  any  COORD 
specifies  a  coordinate  on  a  particular  document  In  the  filing  cabinet. 

c-  projection  a  COORD  -+*  COORD 

A  projection  Is  used  to  map  or  project  each  coordinate  of  a  slave 
surface  area  onto  some  master  surface  area.  Consequently,  it  gives  the  look 
up  instructions  for  references  where  Information  is  being  shared  between 
documents.  For  example.  If  P  is  a  projection,  then  P(c)  is  the  master 
coordinate  whose  appearance  is  given  to  slave  coordinate  c. 

With  this  powerful  device,  a  document  can  be  made  to  share 
information  with  any  document  In  the  filing  cabinet.  It  is  also  the 
projection  which  allows  us  to  display  the  filing  cabinet  information  on  the 
screen  in  any  arrangement  that  we  desire. 

slave  :  projection  — *  F  (COORD) 
slave  e  dom 

master  :  projection  — >  P  (COORD) 
master  a  ran 

The  projection  also  defines  the  scaling  or  distortion  between  the 
master  and  the  slave.  No  restriction  is  given  on  the  size  and  shape  of  either 
the  master  or  the  slave.  Notice  that  several  different  documents  can  be 
mapped  using  a  single  projection. 


PRO J SET  contains  a  list  ot  projections  and  a  list  of 
£  iltex-applys.  For  any  projection  number  n  In  projlist. 
f ilterlist (n)  Is  the  appropriate  filter-apply  function. 

Notice  that  the  second  predicate  suggests  that  the  appropriate  filter 
Is  to  be  applied  to  the  slave  of  the  projection.  Again,  the  reason  is  that 
It  will  be  important  to  Know  what  speck  (or  filtered  speck)  appears  at 
each  coordinate  point. 

A  question  to  be  answered  now  is  how  overlapping  projection  slaves 
will  be  resolved.  The  simplest  solution  requires  a  function  which  will  flatten 
the  list  of  projections  into  a  single  projection.  Of  course,  since 
projection  is  a  function,  there  Is  no  ambiguity  with  a  single  projection. 
The  standard  function  we  will  use  to  do  the  required  flattening  is  called 
update : 


update  (v)  -  v  (1)  •  v  (2)  •  ...§  v  (length(v)) 
where  the  overriding  operator  means: 

rl  •  r2  -  rl  \  dom(r2)  u  r2  (rl  and  r2  are  relations) 

Therefore,  using  update  the  later  projections  in  the  list  will  override  earlier 
projections  in  the  case  of  overlap.  The  order  of  the  projections  in  the 
projlist  can  have  a  significant  effect  on  the  appearance  of  the  documents 
in  the  filing  cabinet  or  as  seen  on  the  screen.  From  the  definition  of 
add-projection  below  it  Is  obvious  that  newly  added  projections  take 
precedence  over  the  other  projections. 

The  updated  projection  list  gives  us  a  single  projection  so 
slave  overlap  Is  no  longer  a  problem,  but  we  still  face  the  question  of  how 
to  traverse  the  projection  network  so  that  we  can  find  the  ultimate  master 
for  any  Input  coordinate.  This  Is  also  easily  resolved  with  one  of  our  standard 
tools,  in  this  case  loop.  Loop  has  the  following  properties: 

loop(R)  -  (R*)  /  doin(R) 

(J(dom(R))  UR);  loop(R)  -  loop(R) 

Therefore,  loop  will  apply  the  flattened  projection  as  many  times  as  required 
to  find  the  ultimate  master  of  a  projected  coordinate.  A  caution  must  be 
fllven  here:  looptupdatefaiojlistj)  may  not  tit  defined  for  all 


coordinates  in  the  slave  of  the  various  projections  in  projlist.  The 
reason  for  the  undefined  ultimate  master  In  these  undefined  cases  Is  circular 
projection  paths  in  the  flattened  projlist.  This  is  the  same  problem  posed 
by  placing  two  or  more  mirrors  In  such  a  manner  that  they  mutually 
reflect — certain  points  seen  on  one  mirror  may  never  be  traceable  through 
all  the  reflections  to  their  source  (ultimate  master). 


Operations: 

The  following  operations  on  the  PROJSET  cause  the  addition,  deletion,  or 
swapping  of  documents  or  the  changing  of  a  filter.  Like  the  operations  on 
the  FILING  CABINET,  these  operations  have  been  kept  very  general. 


ADD-PROJECT  I  ON _ l. 

APROJSET1.2 


projection 
filter -apply 


dom  (p)  -  dom  (fa) 
projlist'  -  projlist  *  <p> 


f ilterlist ' 


filterlist  *  <fa> 


A  projection  (and  Its  associated  f  ilter-apply)  is  added  to  the 
end  of  the  appropriate  list  if  the  domain  of  the  new  f  ilter-apply  Is  the 
slave  of  the  new  projection. 


DELETE-PROJECTION. 
APROJSET1 . 2 


m  <  length  (projlist) 
projlist'  -  delete  (projlist, m) 
filterlist'  -  delete  (filterlist ,m) 


Any  existing  projection  and  Its  filter-apply  can  be  deleted 
by  specifying  the  number  of  the  projection  to  be  removed. 

c. 

SWAP -PROJECT I ON _ 

APROJSET1. 2 
n 
m 


n  <  length  (projlist) 
m  <  length  (projlist) 
projlist'  - 

projlist  f  (n  |-»  projlist  (m)}  •  {m  I— >  projlist  (n)} 
filter list'  - 

filterlist  •  {n  filterlist  (m)}  • 

{m  h*  filterlist  (n) ) 


Swapping  two  projections  reverses  their  order  in  the  list  and 
likewise  moves  the  two  associated  f  ilter-applys .  Since  the  order  of 
projections  in  the  projlist  is  very  important  in  determining  the 
appearance  of  a  document,  the  ability  to  swap  two  projections  Is  required. 

d. 

SWITCH-FILTER _ 

APROJSET1. 2 
n 
f 
C 


n  <  length  (filterlist) 
projlist'  -  projlist 
filterlist'  -  filterlist  • 

{n  h*  filterlist  (n)  •  (f  •  filterlist  (n))  t  C) 


filter 
P( COORD) ) 


A. 


JV. 


This  operation  allows  the  filter  for  part  of  the  projection  slave  to  be 
changed.  Note  that  the  change  is  by  composition  rather  than  replacement. 


DISPLAY  1.3 


Basis: 

Prior:  FILING  CABINET1.1  (Auxiliary  definitions) 

Comments: 

DISPLAY  specifies  what  coordinates  of  which  documents  will  be 
displayed  on  the  screen. 

State  Component  Definition: 


DISPLAYl.  3. 


seearea 


F( COORD) 


FILER  1 


(The  FILER  specification,  which  was  adjourned  to  allow  the  substate 
components  to  be  defined,  can  now  be  restarted.) 

Auxiliary  Definitions: 


background 

background 


COORD 


(XX) 

(Xc) 


This  constant  function  spreads  the  background  value  (eg.  color )  to 


all  coordinates. 


State  Definition: 


FILERJ 


FILING  CAB INET1 . 1 
PROJSET1. 2 
DISPLAY!. 3 


The  FILER,  then,  models  the  complete  filling/viewing  system  by 
combining  the  three  components.  FILING  CABINET  and  PROJSET  specify 
a  very  abstract  Information  sharing  filing  system.  All  three  components  will 
be  used  to  specifiy  a  simple  abstract  windowed  display  system. 


Observations: 

Now  it  is  possible  to  determine  the  appearance  of  the  Information 
in  the  filing  cabinet  and  on  the  user's  screen.  This  is  done  by  creating 
the  following  functions  to  integrate  the  FILER  components. 


♦FILING  CABINET1.1 


COORD  -**  speck 


view' 


(VC  :  COORD  |  dn  (C)  £  dom  (documents)) 

(view*  (C)  -  (background  (colors  (dn  ( C ) ) )  9 

uncurry  (documents))  ( C ) ) 


This  function  places  the  documents  on  their  background  paper  colors. 
Given  a  FILING  CABINET,  any  coordinate  on  any  existing  document  will 
determine  a  speck.  Any  coordinate  which  Is  not  in  the  extent  of  the  document 
(ie.  not  in  the  domain  of  the  document)  will  appear  as  the  appropriate 
background  speck. 

Remember. 

documents  a  docname  -»*  (coordinate  -**  speck) 

and 

uncurry  (documents)  -  (docname  *  coordinate)  -+*  speck 

-  COORD  •**  speck 


b. 

PROJECTED-APPEARANCE _ 

♦F I LERI 

view  :  COORD  speck 

prjview'  :  COORD  -**  speck 


prjview'  -  (background  (filecolor)  9  view) 

•  loop  (update  (projlist)) 


This  function  adds  the  shared  information  look  up  instructions  defined 
by  the  projections  to  the  documents.  The  projection  list  flattened  by 
update  will  be  applied  repeatedly  by  loop  until  a  document  coordinate 


outside  the  domain  of  the  flattened  projection  list  is  produced.  (If  the  loop 
does  not  terminate,  the  result  Is  undefined.)  This  coordinate  will  use  the 
document  appearance  of  the  previous  function  to  determine  Its  speck  If  the 
coordinate  is  on  an  existing  document  or  its  paper,  if  the  coordinate  is  not 
on  one  of  the  papers  in  the  filing  cabinet,  then  it  will  contain  the  filing  cabinet 
background  color. 


APPEARANCE _ 

♦FI LERI 

prjview  :  COORD  -**  speck 

fileview'  :  COORD  -**  speck 


fileview'  (C)  -  ((background  (f (speck))  9 

update  (f ilterlist) )  (C))  o 
prjview  (C) 


Finally,  this  function  determines  the  appearance  of  the  entire  filing 
cabinet.  It  applies  the  appropriate  filter  to  each  speck  produced  by 
the  PROJECTED-APPEARANCE .  If  the  given  coordinate  Is  not  an  element 
of  a  projection  domain,  then  the  coordinate  will  likewise  not  be  a  element 
of  a  f  ilter-apply.  in  this  case,  the  identity  function.  J( speck)  will 
leave  the  speck  unchanged.  (Remember  that  the  identity  function.  J( COORD) 
is  built  Into  loop.) 

d. 

D I  SPLAY-APPEARANCE. _ _ _ _ 

♦F I LERI 

fileview  :  COORD  -**  speck 

picture*  :  COORD  -+*  speck 


picture'  -  fileview  t  seearea 

f 


This  last  observation  allows  us  to  restrict  our  view  of  the  filing  cabinet 
to  those  areas  which  are  of  interest  to  the  user.  We  now  have  the  ability 


to  formally  specify  the  picture  that  the  user  will  see  displayed  on  his  screen: 

DISPLAYED  a  FILE-APPEARANCE;  PROJECTED-APPEARANCE ; 

APPEARANCE;  DISPLAY-APPEARANCE 

We  should  again  note  that  this  is  a  partial  function  since  no  attempt 
has  been  made  to  restrict  circular  projection  networks  from  the  PROJSET. 

Operations: 

The  operations  defined  below  will  not  be  presented  as  FILER  to 
FILER  functions.  The  reason  for  this  is  quite  simply  to  delay  unnecessary 
promotion  (and.  hence,  complication  of  simple  functions)  and  to  put  off 
premature  design  decisions.  For  the  same  reason,  the  operations  previously 
defined  on  the  various  components  of  the  state  will  not  all  be  promoted  to 
state  to  state  functions. 

The  projection  concept  is  a  very  powerful  one.  We  shall  now  use 
projections  as  a  convenient  means  of  changing  parts  of  the  state  in  addition 
to  their  previous  use  as  a  state  component  In  the  PROJSET.  The  projections 
used  to  change  parts  of  the  abstract  machine  state  we  will  refer  to  as  updating 
protections  to  indicate  that  they  do  not  (necessarily)  coincide  with  the  state 
component  projections.  We  can  now  make  state  changes  by  composing  part 
of  the  state  with  an  updating  projection.  The  advantage  of  composition 
changes  rather  than  outright  replacement  of  state  components  is  that  it  makes 
reversing  (ie.  undoing  the  effects  of)  the  operation  possible.  The  following 
table  summarizes  the  operations  which  can  be  developed  from  state 
components  and  updating  projections: 

1.  move: 

a  projection  (frame,  image,  or  both) 
an  area  of  filter  application 
a  document  (part) 
an  area  seen  on  the  screen 

2.  change  the  size/shape  of: 

a  projection 

an  area  of  filter  application 

a  document  (part) 

an  area  seen  on  the  screen 


a. 


change-slave, 

change-master  :  projection  *  projection 
change-slave  (up,p)  a  p  «  up 
change-master  (up,p)  a  up  •  p 


projection 


change-projection  :  projection  x  projection  -►*  projection 
change-projection  a  (Xup,p  |  up  €  partial- injection) 

up  o  p  o  up-1 


This  will  allow  the  slave  and/or  master  of  a  projection  in  PROJSET 
to  be  moved,  changed  in  size  or  shape,  scaled  or  skewed. 


SLATE 

uroanNo 


CHANQE-SUWE 


SLAVE 

DOCUMENT 


esi 


SLAVE 

DOCUMENT 


MASTER 


MASTER 


CHANGE -MASTER 


CHANGE- PROJECTION 


FIG.  Ill— 9  —  Projection  Changing. 


change-filter-area  :  filter-apply  *  projection  — *■ 

f ilter-apply 


change-filter-area  a  op(») 


We  can  change  the  area  of  application  of  the  filter(s)  associated  with 
a  projection. 


c. 


change-document  :  (docname  -**  surface)  — >  projection 

(docname  -**  surface) 


change-document  a  ( XS ) 

(XC  :  COORD  I  dn(C)  €  dom  (S)) 
(XD  :  COORD  |  dn(D)  e  dom  (S)) 


S  • 

(dn(C)  |~+  (S(dn(C))  •  (S(dn(D))  ®  {coord(C)  |— » 


coord(D) ) ) ) ) 


This  function  aUows  the  projection  (movement)  of  a  document  (part) 
and  can  thereby  change  the  size  or  shape  of  the  slave  document.  It  does 
not  affect  the  master  document  area  or  allow  the  creation  of  a  new  document. 


d. 

change-display  :  projection  *  P(COORD)  — ►  .P(COORD) 
change-display  a  (XP,s) 

P  0  s  D 


This  changes  the  document  areas  displayed  on  the  screen. 


FILER2 


Basis: 

Prior:  FILER1 

Comments: 

This  specification  restricts  the  abstract  coordinate  system  of  FILER1 
to  a  two  dimensional  Cartesian  system.  This  restriction  recognizes  the  obvious 
choice  of  coordinate  systems  for  our  (textual)  documents  since  a  document 
is  normally  a  flat,  two  dimensional  object  and  since  the  mathematical  basis 
of  a  Cartesian  space  is  widely  understood. 

Requirements  /  Design  Decisions: 

|[ ID  The  coordinate  system  is  two  dimensional. 

Auxiliary  Definitions: 

Add  the  following  to  the  current  theory: 


The  other  lexicographic  relational  operators  are  similar. 

The  overloading  of  operators  should  not  cause  confusion  since  the 
context  will  easily  determine  which  operator  is  intented. 

b.  coordinate  a  PAIR  [  real  ]  |[1J 

Here  we  have  defined  our  previously  abstract  notion  of  coordinate. 

State  Definition: 

F ILER2  [speck,  docname]  a 

F I LERI  [coordinate  -  PAIR  [real],  speck,  docname] 

We  have  restricted  the  state  space  to  use  a  coordinate  plane  which 


is  two  dimensional. 


FILER3 


Basis: 

Prior:  FILER2 

Forward:  PROJSET2.2  /  DISPLAY2.3 

Comments: 

This  is  the  first  step  In  limiting  the  very  abstract  family  of  systems. 
This  level  will  introduce  various  design  decisions  which  are  large  in  scope 
and  effect.  The  most  significant  of  these  decisions  is  the  definition  of  the 
coordinate  system  for  the  documents  and  the  screen  as  two  dimensional, 
rectangular,  and  Integer.  With  this  decision,  it  was  also  concluded  that 
scaling  and  skewing  of  information  is  not  required  in  this  system. 

Other  decisions  limit  the  power  of  projections  by  1)  requiring  that 
the  slave  and  master  of  any  projection  each  be  confined  to  a  single  document 
paper,  and  2)  limiting  the  allowable  filters  to  one  per  projection  in  addition 
to  the  identity  filter.  Finally,  the  display  is  to  show  only  a  single  document 
selected  from  the  filing  cabinet. 

These  decisions  were  taken  because  they  typify  a  certain  class  of 
systems:  those  which  deal  mainly  with  textual  documents,  not  requiring  high 
flexibility  of  document  design  in  shape  and  appearance.  Of  course,  a  large 
number  of  systems  still  fit  into  the  family  defined  by  this  level  of  specification. 


PROJSET3.2 


Basis: 


Prior:  PR0JSET1.2 


Comments: 

This  specification  simplifies  the  projections  by  requiring  that  slave  and 
master  of  a  projection  must  define  areas  on  single  documents.  This  in  no 
way  diminishes  the  power  of  the  set  of  projections  but  does  restrict  the  power 
of  each  individual  projection.  The  second  restriction  presented  here  will  allow 
only  a  single  area  of  each  projection  to  be  modified  by  a  filter.  Again,  this 
does  not  reduce  the  power  of  the  whole  projection  set  but  does  simplify 
individual  projections. 

Requirements  /  Design  Decisions: 

|[  1  ]  The  slave  and  master  of  a  projection  must  each  be  an  area  on  a  single 
document. 

|[2]  Each  filter-apply  can  use  only  one  filter  besides  the  identity. 
Stale  Component  Definition: 

PROJSET3 . 2 _ 

PROJSET1 . 2 

[1]  (Vx  :  dom  (projlist))  (3a, b  :  docname) 

(dom  (projlist  (x))  c  (COORD  |  dn  ■  a)  a 
ran  (projlist  (x))  c  (COORD  |  dn  ■  b)  ) 

[2]  (Vx  :  dom  (projlist))  (3f  :  filter) 

(ran  (filterlist  (x))  -  (f)  u  J(speck)) 


The  appropriate  restrictions  are  added  to  the  component  state  space 


definition. 


DISPLAY3.3 


Basis: 


Prior:  DISPLAY!  .3 


Comments: 

Our  current  design  gives  us  the  option  of  seeing  parts  of  a  variety 
of  different  documents  or  of  selecting  a  single  document  to  view  at  any 
particular  time.  Of  course,  in  the  latter  case  the  selected  document  could 
be  a  complex  mosaic  of  parts  of  the  other  documents. 

We  will  choose  this  latter  display  technique  because  it  simplifies  the 
definition  of  the  relationship  between  what  the  user  wishes  to  see  (seearea) 
and  the  form  of  that  area  presented  on  the  screen.  That  is.  with  this 
definition,  the  screen  is  simply  an  area  from  one  of  the  documents  In  the 
filing  cabinet. 

Requirements  /  Design  Decisions: 

1 1 1  The  screen  displays  part  of  a  single  document  at  one  time. 

State  Component  Definition: 

DISPLAY3 . 3 _ 

DISPLAY 1.3 


|[  1 D  (3x  :  docname) 

dn  flseeareaO-  {x} 


FILERS 


Requirements  /  Design  Decisions: 

|[1]|  The  coordinate  frame  Is  two  dimensional,  rectangular,  and  Integer. 

State  Definition: 

F I LER3 _ : _ 


FILER2  [coordinate  -  PAIR  [  MNT  ]] 
(PROJSET1. 2  >■»  PROJSET3 . 2 ; 
D I  SPLAY  1. 3  P-fr  DISPLAY3 . 3 ) 


CHAPTER  IV 


The  Abstract  Baseline 


This  case  study  applies  the  techniques  of  the  proposed  software 

development  methodology  In  a  limited  and  controlled  demonstration.  The  case 
study  project  is  a  moderately  sized,  single  person  development  which  assumes 
the  existence  of  a  typically  naive  client.  Since  this  study  represents  the  first 
test  of  a  potentially  complex  methodology,  it  is  appropriate  that  the  degrees 
of  freedom  of  the  project  be  limited  by  virtually  eliminating  the  interactions 
(with  clients,  management,  design  team  members,  implementors,  etc.)  that 
would  exist  in  a  practical  development.  In  actuality,  the  portions  of  the 
methodology  skipped  by  this  initial  controlled  project  (eg.  configuration 

management,  resource  management  and  estimation,  verification  and  validation, 
etc.)  are  generally  aspects  which  are  Imported  from  other  design  strategies 

and.  hence,  are  not  unique  to  this  methodology.  The  case  study  does 

emphasize  the  aspects  which  uniquely  form  the  kernel  of  the  methodology: 
eg.  the  structuring  of  the  formal  specification,  the  use  of  baselines  within 
the  formal  specification,  documentation  of  the  limitative  design  technique,  the 
use  of  very  abstract  starting  points,  etc. 

It  is  important  to  remember,  however,  that  the  methodology  was 
designed  for  large,  multi-person  software  projects.  Therefore,  results  of  this 
scaled  down  case  study  must  ultimately  be  extrapolated  to  the  large 
development  where  communication  among  participants  and  management 
control  are  of  the  highest  priority  for  an  efficient  project.  It  Is  only  at  this 
large  scale  and  over  a  full  life  cycle  (the  case  study  does  not  attempt  to 
simulate  product  testing,  handover,  operation,  or  maintenance)  that  the  true 
cost  reduction  benefit  of  this  methodology  can  be  determined. 


This  chapter  contains  a  portion  of  the  abstract  baseline 
documentation.  This  documentation  includes  the  Informal  requirements 


definition,  the  problem  decomposition,  the  formal  abstract  design  specification 
(references),  and  the  provisional  user's  manual. 

IV.  1  Requirements  Definition. 

The  object  of  this  case  study  is  an  information  sharing,  windowed 
screen  editor  for  a  personal  computer  system.  The  requirements  of  the 
desired  system  are  given  informally  and  only  very  generally  by  the  following 
guidelines: 

(1)  Only  those  parts  of  the  textual  Information  that  are  currently 
visible  can  be  updated.  All  the  effects  of  each  update  are 
immediately  visible,  and  can  be  Immediately  undone. 

(2)  All  textual  information  In  the  system  can  be  brought  Into  view 
and  updated  by  uniform  methods.  There  are  no  specialized 
techniques  necessary  for  manipulating  file  names,  directories, 
dates,  version  numbers,  etc.  All  these  are  documentary  information, 
accessible  and  updatable  in  the  same  way. 

(3)  The  editing  commands  should  be  simple,  low  risk  commands 
which  do  not  rely  on  a  hierarchy  of  modes. 

(4)  All  user  Interfaces  to  the  system  should  be  consistent  and 
designed  to  reinforce  the  user's  confidence  in  and  understanding 
of  the  system. 

it  is  assumed  that  no  firm  Information  is  available  about  the  hardware 
to  be  selected  for  the  customer's  system  until  such  a  selection  Is  required 
for  further  progress.  However,  from  the  nature  of  the  case  study  system 
it  is  (reasonably)  presupposed  that  the  hardware  would  include  a  screen  with 
limited  or  no  graphical  capabilities,  and  whose  character  set  could  be  stored 
encoded  In  the  memory  of  the  computer. 

IV.2  Decomposition. 

The  first  decision  mace  in  the  development  of  the  windowed  screen 
editor  sy  tern  was  to  separate  the  flling/vlewing  functions  of  the  system  from 
the  editing  and  the  user  command  interface  functions.  This  decision 
represents  a  logical  decomposition  of  a  system  which  could  be  difficult  to 
reason  about  effectively  if  taken  as  a  whole. 

The  filing/viewing  system  will  Include  both  the  Information  sharing  and 
the  windowing  aspects  of  the  system.  All  decisions  about  how  information 


is  stored  and  represented  to  the  user  will  be  made  in  this  component.  This 
will  comprise  the  basis  of  the  system. 

The  second  component,  the  editor,  will  deal  with  the  design  of  a 
system  to  update  textual  documents  within  the  filing  system  created  in  the 
first  component.  A  subset  of  the  normal  editing  functions  will  be  available 
to  the  user  in  the  ultimate  system  design. 

The  standard  components  of  the  machine,  the  user,  and  the  system 
interfaces  will  be  recomposed  with  the  two  explicitly  decomposed  modules 
as  required  to  complete  the  system. 


IV.3  Abstract  Design. 

The  first  component  of  the  design  has  been  formulated  very  abstractly 
and  is  presented  as  Chapter  III.  A  Family  of  Visible  Filing  Systems. 

The  second  component  of  the  abstract  design  is  drawn  from  previous 
work  on  the  formal  definition  of  an  edltor.[Sufr!n.81b]  That  abstract  editor 
design  has  been  slightly  modified  and  presented  In  the  style  of  this 
methodology  in  the  Specification  Library  (Appendix  A).  A  good  explanation 
of  our  editor  design  appears  In  [Sufrln,81b]  and.  therefore,  will  not  be  repeated 


1.  In  the  Beginning... 

The  terminal  screen  you  are  using  Is  Screenwriter's  way  of 
communicating  with  you.  it  will  hold  24  lines  of  information;  each  line 
containing  as  many  as  80  characters.  The  very  bottom  line  Is  special  because 
Screenwriter  will  use  It  to  ask  you  questions,  make  comments,  or  indicate 
when  you  have  done  something  wrong.  Whenever  something  appears  on  this 
line,  the  bell  will  ring  to  draw  your  attention  to  it. 

The  keyboard  attached  to  the  screen  is  your  device  for  communicating 
commands  and  answers  to  Screenwriter.  The  keyboard  is  divided  into  three 
parts;  the  character  keys,  the  special  command  keys,  and  the  directional  keys 
(see  fig.  1).  The  character  keys  are  In  the  same  arrangement  as  you  would 
find  on  a  typewriter.  The  special  command  keys  are  arranged  in  three  rows 
and  five  different  areas.  The  three  rows  from  bottom  to  top  represent 
increasingly  dangerous .  commands,  and  some  care  must  be  taken  in  using 
the  top  row  of  commands.  In  order  to  cause  you  to  think  about  your  use 
of  these  uppermost  commands  and  to  prevent  an  accident,  the  auxiliary  key 
must  be  depressed  simultaneously  with  any  other  key  In  the  top  row  for  the 
command  to  be  communicated  to  Screenwriter.  The  lower  two  rows  of  special 
command  keys  require  only  a  single  key  depression  for  each  command.  The 
five  areas  of  special  command  keys  will  be  discussed  In  the  order  they  appear 
on  the  keyboard.  When  a  key  (command)  Is  discussed  below,  it  will  be 
underlined  for  emphasis. 


DOCUMENTS 


□  □  □  □ 

nun  mi  mn  miti  i 

o  □  •  ft  □ 


WINDOWS 

,EL 

□  □ 


STAINED 

BUILDING 

GLASS 

PROJECTIONS 

□ 

□ 

RCMOK 

□ 

□  □  □ 

CRUtl 

CAUCM  OttITf  WOJO)R 

□  □  □ 

MOVE  ATTRACT  ORlMQ 

•  •  • 

MISCELLANEOUS 


□  □  □ 

MW  CUM  OUT 


STANDARD 

CHARACTER 

KEYBOARD 


□  □ 

MQC  TOR 

L* 

□  □ 


Ftp.  UM-1  —  The  Keyboard 


When  you  call  Screenwriter  into  action  it  will  welcome  you  with  a 
message  on  the  last  line  of  the  screen.  The  very  first  time  you  use  It.  the 
upper  23  lines  of  the  screen  will  be  empty  to  show  you  that  your  new  office 
is  empty,  ready  for  you  to  go  to  work.  In  subsequent  uses,  you  may  start 
with  a  picture  telling  what  information  had  previously  been  stored  with 
Screenwriter.  This  picture  is  called  the  home  picture  because  you  will  return 
to  it  regularly. 

The  Paper. 

For  you  to  create  a  document  (eg.  letter,  memo,  report,  etc.),  the 
first  thing  you  will  require  is  a  blank  sheet  of  paper.  The  beginning  of  this 
blank  sheet  is  easily  obtained  by  depressing  the  create  document  key.  The 
paper  will  be  given  to  you  one  line  at  a  time  exactly  as  Is  done  on  a 
typewriter.  Each  line  will  hold  up  to  80  characters  of  typed  information,  so 
your  sheet  of  paper  will  be  exactly  as  wide  as  the  screen.  The  bright  flashing 
line  on  the  screen  is  called  the  cursor  and  is  used  to  point  to  the  current 
location  on  your  paper.  After  the  create  document  key  Is  pushed,  the  cursor 
will  be  in  the  upper  left  hand  corner  of  the  screen  and  will  point  to  the 
first  position  on  your  new  one  line  sheet  of  paper.  This  first  line  is  called 
the  name  line  because  it  is  here  that  you  will  type  any  identifying  information 
about  the  document  you  are  creating  (eg.  name,  title,  draft  or  final,  date, 
etc). 

The  Type. 

To  put  this  name  information  on  the  first  line  or  to  add  information 
to  any  future  line  is  exactly  the  same  as  for  a  conventional  typewriter;  simply 
type  the  characters  that  you  wish  to  appear  on  the  page.  After  each  character 
that  you  type  the  cursor  will  move  to  the  next  position  on  the  line.  However, 
the  cursor  will  stop  at  the  end  of  a  line  and  refuse  to  go  any  further,  just 
as  your  typewriter  would  not  let  you  beyond  your  margin.  Also  like  your 
(electric)  typewriter  is  the  manner  In  which  you  move  to  the  next  line  on 
the  paper  —  depress  the  return  key.  As  you  would  expect,  the  return  key 
will  cause  the  cursor  to  move  to  the  beginning  of  a  new  blank  line,  ready 
for  typing.  Of  course,  a  completely  blank  line  In  your  document  (eg.  double 
spacing)  is  the  result  of  two  returns  in  a  row. 


The  Arrows. 


At  some  point  in  the  creation  of  your  document,  you  are  likely  to 
make  a  ‘typo*,  but  don't  despair)  The  correction  of  errors  is  one  of  the 
advantages  of  Screenwriter  over  your  conventional  typewriter.  To  fix  an  error 
in  some  part  of  your  document,  simply  use  the  arrow  keys  to  move  the  cursor 
to  the  location  of  the  error  and  retype  on  top  of  the  erroneous  part.  The 
new  character  you  type  will  replace  the  original  character  that  was  there  (no 
erasing  is  requiredl).  The  arrow  keys  allow  you  to  roam  around  your  document 
making  changes  as  you  desire.  However,  the  arrow  keys  will  not  push  the 
cursor  off  the  document  you  are  currently  creating. 

The  insert  and  Delete  Keys. 

Two  other  types  of  easy  corrections  are  possible  with  Screenwriter. 
The  delete  command  will-  cause  the  character  which  is  pointed  to  by  the  cursor 
to  disappear  and  the  rest  of  the  line  will  be  joined  back  together  as  if  the 
deleted  character  had  never  been  typed.  Deleting  a  blank  character  after 
the  end  of  a  line  will  cause  the  line  up  to  that  point  and  the  following  line 
to  be  joined  Into  a  single  line  (unless  doing  so  would  make  the  resulting 
line  longer  than  allowed  by  the  margins.)  One  character  is  deleted  each 
time  the  delete  key  is  pushed. 

Inserting,  as  you  might  expect,  does  the  exact  opposite  of  the  delete 
command.  The  Insert  command  will  switch  the  machine  to  the  insert  mode, 
thereby  causing  characters  to  be  inserted  before  the  character  denoted  by 
the  cursor.  Inserting  a  return  In  a  line  will  cause  the  remainder  of  the  line 
to  the  right  of  the  new  carriage  return  to  be  moved  to  a  new  line.  The 
word  ‘INSERTING*  will  appear  on  the  last  line  of  your  screen  to  remind  you 
that  any  character  you  type  will  be  Inserted  rather  than  replace  an  existing 
character.  Hence,  many  characters  can  be  Inserted  with  one  push  of  the 
Insert  key.  Screenwriter  will  know  the  Insert  command  is  over  when  you 
depress  any  key  other  than  a  character  key.  (If  you  will  notice,  there  is 
an  ***  on  the  Insert  key  on  your  keyboard.  This  corresponds  to  the  •** 
on  the  accept  key.  The  accept  key  is  a  very  safe  key  and  can  be  used 
at  any  time  without  fear,  it  will  safely  end  any  **'ed*  command  which  has 
been  started,  but  will  do  nothing  else.) 
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now  is  a  time 


now  is  time 
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now  is  th  time 


now  is  the  time 


FIG.  UM-2  —  Insert  and  Delete 


The  Pages. 

With  standard  typewritten  documents  you  are  used  to  the  paper  being 
a  constant  length  (say  A4)  and  any  document  of  a  greater  length  requiring 
more  than  one  page.  Screenwriter  has  a  variable  size  for  the  length  of  the 
piece  of  paper  you  write  on  —  as  we  noted  earlier  the  paper  will  grow  one 
line  at  a  time  so  that  it  is  always  just  long  enough  to  hold  your  document. 
A  screen  page  of  this  document  you  create  will  be  any  23  consecutive  lines 
that  are  seen  on  your  terminal  screen.  (Remember,  the  24th  line  is  used 
for  Screenwriter  to  talk  to  you.)  As  you  add  more  than  23  lines  to  your 
document,  you  will  notice  that  lines  disappear  off  the  top  of  the  screen  as 
new  ones  are  added  to  the  bottom.  This  vertical  shifting  of  the  information 
visible  on  the  screen  is  known  as  scrolling. 

Scrolling  is  rather  like  what  happens  when  you  view  a  film  strip  with 
a  projector.  The  film  strip  (document)  can  be  almost  any  length  but  you 
will  be  able  to  see  only  one  part  of  it  (screen  page)  at  a  time.  The  projector 
scrolls  forward  to  move  to  the  next  part  or  scrolls  back  to  reveal  the  previous 
part.  All  parts  but  the  one  being  projected  are  hidden  from  view  on  one 
of  the  two  film  reels.  Similarly,  all  parts  of  your  document  will  be  hidden 
except  the  part  which  has  been  scrolled  onto  your  terminal  screen. 

Scrolling  to  correct  your  document  is  accomplished  one  line  at  a 
time  by  using  the  up  arrow  for  scrolling  up  the  document,  or  the  down  arrow 
for  scrolling  down  the  document.  When  the  cursor  reaches  the  bottom  (top) 
of  the  screen  page,  further  use  of  the  down  (up)  arrow  will  cause  the 
Information  visible  on  the  screen  to  shift  up  (down)  one  line  and  the  next 
(previous)  line  to  appear  on  the  bottom  (top)  of  the  screen  page. 


If  your  document  is  very  long.  It  may  be  Inconvenient  to  scroll  through 
It  one  line  at  a  time  In  search  for  a  particular  line  or  word.  Therefore. 

It  Is  possible  to  scroll  through  your  document  a  full  page  (23  lines)  at  a 

time  using  the  page  up  or  page  down  command.  The  page  down  command, 

for  example,  will  cause  the  line  previously  just  off  the  bottom  of  the  screen 

page  to  be  moved  to  the  top  of  the  new  screen  page.  Additionally,  the 
beginning  or  end  of  a  document  can  be  scrolled  Into  view  with  the  to£  or 
bottom  command. 

The  Printed  Copy. 

Once  a  document  has  been  created  and  corrected,  you  will  probably 
want  a  printed  copy  of  It  to  send  out.  give  to  your  boss.  etc.  Getting  a 
printed  copy  Is  as  easy  as  giving  the  print  command.  If  the  cursor  is  In 
the  document's  name  line  when  this  key  is  pushed,  then  the  entire  document 
Is  printed.  If  the  cursor  Is  anywhere  else  in  the  document  at  the  moment 
print  is  pressed,  then  only  the  current  screen  page  is  printed.  When 
Screenwriter  is  finished  printing,  it  will  tell  you  so  on  the  last  line  of  your 
screen. 

The  Filing  Cabinet. 

If  the  document  you  have  created  is  something  that  you  wish  to  save 
for  reference,  or  further  work,  then  place  it  in  Screenwriter's  filing  cabinet. 
Filing  a  document  is  done  very  simply  with  the  fNe  command  key.  This 

command  files  away  the  document  exactly  as  you  currently  have  ft. 

The  Waste  Bln. 

If  the  document  you  have  created  Is  something  that  you  wish  to  throw 
away  because  you  have  no  further  use  for  it.  then  place  it  In  Screenwriter's 
waste  bln.  Warning:  throwing  a  document  away  is  permanent  since 

Screenwriter  will  not  retrieve  from  the  waste  bin.  Therefore,  the  process  to 
get  rid  of  a  document  is  slightly  more  Involved  than  the  process  to  file  a 

document.  First,  you  must  press  the  throw  away  key  which  will  cause 

Screenwriter  to  ask  the  question:  "DO  YOU  REALLY  WISH  TO  LOSE  THIS 
DOCUMENT?"  If  you  give  any  answer  to  this  question  except  "Y",  then  the 
answer  and  the  throw  away  command  will  be  ignored.  The  extra  difficulty  of 
this  command  will  give  you  time  to  consider  your  decision  to  throw  away 


a  document  you  have  created  and  to  further  protect  you  from  accidental 
destruction  of  a  document.  Completion  of  the  throw  away  command  (l.e.  an 
answer  of  ‘V*  to  the  question)  will  cause  the  document  to  disappear  and 
the  screen  to  return  to  the  home  picture. 

2.  Seeing  Is  Believing... 

Any  number  of  documents  can  be  created,  corrected,  printed,  filed, 
or  thrown  away  in  the  manner  described  in  the  preceding  chapter.  However, 
these  commands  do  not  fully  allow  you  to  utilize  the  flexibility  and  power  of 
Screenwriter.  To  tap  this  power  you  must  understand  how  to  change  the 
picture  you  see  on  the  screen  to  suit  your  requirements.  Thus  far.  you  have 
been  able  to  see  one  of  two  pictures  on  the  screen.  The  first  possibility 
called  the  home  picture;  was  seen  immediately  upon  setting  Screenwriter  into 
action  or  as  a  result  of  throwing  away  a  document  you've  just  created.  The 
home  picture  (which  will  be  explained  more  fully  in  a  moment)  is  a  very 
important  view  of  Screenwriter  and  is  probably  the  starting  place  for  most 
of  the  work  you  wilt  do.  The  second  picture  you  have  been  able  to  see  on 
your  screen  is  one  which  Included  part  of  the  single  document  you  were 
working  on  at  the  time.  This  picture  was  visible  between  the  create  command 
and  the  file  or  throw  away  command.  Remember  that  while  working  on  a 
document.  Screenwriter  would  not  let  you  see  anything  on  your  screen  except 
that  document.  Now  it  is  time  that  you  controlled  what  is  visible  on  your 
screen. 

The  Projections. 

Imagine  for  a  moment  a  big  white  tabletop  upon  which  Screenwriter 
could  display  any  of  the  documents  you  have  filed  in  its  filing  cabinet.  It 
could  do  this  with  one  of  the  projection  systems  shown  below  (fig.  3).  The 
camera  focuses  on  the  document  (or  part  of  it)  and  that  Information  seen 
by  the  camera  is  projected  onto  the  tabletop.  Certainly  if  you  were  given 
enough  of  these  projection  systems,  you  could  lay  the  documents  In  the  filing 
cabinet  on  the  tabletop  in  any  arrangement  you  desired,  and  that  is  exactly 
what  you  will  do. 


1ABLETOP 
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FIG.  UM-3  —  A  Projection  System 


Your  first  comment  at  this  point  might  be:  *1  have  imagined  a  very 
large  tabletop  but  all  I  see  Is  23  eighty  character  linesl*  And  right  you  are. 
The  size  of  your  terminal  screen  limits  you  to  seeing  only  23  consecutive 
lines  of  the  tabletop,  but  you  can  control  which  lines  you  see  by  a  technique 
you  have  already  discovered  —  scrolling.  Remember  the  arrows,  page  up, 
and  page  down?  What  those  keys  actually  did  was  change  the  area  of  the 
tabletop  visible  on  your  screen,  if  you  look  again  at  the  arrow  keys,  you 
will  note  that  there  are  also  two  horizontal  arrows  which  allow  you  to  ad/ust 
left  or  right  to  any  80  character  segment  of  tabletop.  Of  course,  the  tabletop 


vv  s  *. 


has  edges,  and  you  would  not  expect  to  be  able  to  see  beyond  the  edge 
of  the  tabletop.  For  simplicity,  let's  call  the  area  of  the  tabletop  that  is 
visible  on  the  screen  the  picture  area.  As  you  recall,  the  picture  area  when 
you  were  creating  a  new  document  was  called  the  screen  page. 

Having  resolved  that  problem  you  might  wonder:  *How  do  I  remember 
and  find  all  of  the  documents  I  have  created  and  filed  away?"  To  answer 
that  we  return  to  explain  the  home  picture.  Starting  In  the  upper  left  hand 
corner  of  the  (rectangular)  tabletop  you  have  just  Imagined,  begin  to  project 
the  name  lines  of  all  the  documents  you  created  and  filed  in  Screenwriter. 
Project  them  onto  the  tabletop  In  the  order  they  were  created,  each  below 
the  previous  one.  Having  arranged  the  name  lines  of  all  documents  in  this 
manner,  insert  a  bar  underneath  each  name  line  to  represent  the  number 
of  lines  in  that  document  (le.  the  longer  the  bar  the  longer  the  document). 
What  you  just  imagined  Is  the  home  picture.  No  matter  what  part  of  the 
tabletop  is  visible  on  the  screen.  It  Is  simple  to  return  to  the  home  picture 
—  simply  push  the  home  key.  While  you  have  the  home  picture  on  your 
screen  the  last  line  will  display  the  words:  'HOME  — **  DOCUMENTS  IN  THE 
FILE*  (where  **  will  be  replaced  with  the  document  count). 


Home  Document 
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HOME  —  4  DOCUMENTS  IN  THE  FILE 


FIG.  UM-4  —  The  Home  Picture 

Finally,  you  might  ask:  "What  happens  when  one  of  the  projections 
overlaps  another  projection  on  my  Imagined  tabletop;  is  there  a  double 


so  that  in  case  of  overlap  only  the  stron 
area  of  overlap.  The  rule  Is:  the  newer 
older  projections. 
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by  a  dark  line  which  looks  like  a  window  frame.  At  the  top  of  the  window 
is  always  the  name  line  of  the  document  projected  Into  the  window  or  as 
much  of  it  as  will  fit  in  the  width  of  the  window,  (see  fig.  6)  The  area  of 

a  window  Is  defined  by  the  cursor  location  on  the  screen  at  the  time  you 

push  the  create  window  key.  To  position  the  window  correctly,  place  the 
upper  left  corner  of  the  screen  exactly  at  the  tabletop  spot  where  you  want 

the  upper  left  corner  of  the  window  to  be.  Now,  move  the  cursor  right  and 

down  until  it  is  in  the  spot  which  is  to  be  the  lower  right  corner  of  the  window. 
Having  done  this,  the  window  area  is  defined  by  the  area  from  the  top  of 
the  screen  to  the  line  including  the  cursor  and  from  the  left  edge  of  the 
screen  to  the  column  including  the  cursor.  In  other  words,  the  line  from 
the  upper  left  corner  of  the  screen  picture  to  the  cursor  becomes  the  diagonal 
of  the  new  window.  Note  that  the  largest  window  you  can  define  in  this 
manner  is  one  the  size  of  the  screen.  When  the  window  is  the  size  you 
desire,  push  the  create  window  key.  This  key  will  draw  the  dark  line  frame 
around  the  area  you  have  defined  and  clear  the  area  inside  the  frame.  After 
a  moment.  Screenwriter  will  take  you  to  the  home  picture  so  that  you  can 
pick  the  document  you  want  projected  to  the  window.  The  bottom  line  will 
say  "CHOOSE  A  DOCUMENT  TO  PROJECT.  PLEASE*  to  remind  you  of  your 
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FIG.  UM-8  —  Windows 


To  get  the  proper  document  Into  the  window  you  have  created,  move 
the  cursor  to  the  appropriate  name  line.  Now.  move  the  cursor  across  the 
length  bar  under  the  name  line  until  it  corresponds  to  the  approximate  area 
of  the  document  that  you  wish  to  see  In  the  window.  Each  position  on  the 
length  bar  represents  10  lines  In  your  document.  After  the  cursor  is  In  the 
proper  place  in  the  name  line,  depress  the  choose  key.  This  action  will 
return  the  screen  (and  cursor)  to  the  area  of  the  tabletop  where  your  newly 
defined  window  can  be  seen.  In  the  window  will  be  that  portion  of  the 
document  you  selected  via  the  length  bar. 

If  you  wish  to  get  an  entire  document  from  the  filing  cabinet  and 
project  it  to  the  tabletop  there  is  another,  simpler  method  that  you  may  use. 
The  choose  key  will  project  the  entire  document  selected  by  the  cursor  to 
the  area  starting  below  the  home  picture  If  a  window  has  not  been  defined 
(ie.  you  did  not  depress  the  create  window  key  immediately  prior  to  the  choose 
command.)  Remember  that  the  home  key  will  take  you  to  the  name  line 
area  of  the  tabletop  anytime  you  wish  to  display  an  entire  document  in  this 
manner. 

The  Window  Changes. 

Now  that  projections  to  the  tabletop  have  been  created  by 
Screenwriter,  you  may  find  that  changes  in  the  size,  placement  or  content 
of  the  window  would  be  useful.  Well,  it  is  quite  possible  to  make  any  of 
those  changes  without  difficulty.  For  all  of  these  commands,  first  pick  the 
window  you  wish  to  change  by  placing  the  cursor  within  it. 

Let's  see  how  to  change  the  size  of  a  window.  The  single  rule  you 
must  br  aware  of  In  adjusting  the  size  of  window  Is  that  the  window  can 
never  be  larger  than  the  document  paper  being  projected  to  it.  So  for 

example,  it  Is  not  possible  to  expand  a  window  beyond  80  characters  wide 
since  that  is  the  maximum  document  paper  and  projection  width.  With  this 

rule  in  mind,  push  the  window  expand  or  window  retract  key  depending  on 
whether  you  wish  to  increase  or  decrease  the  size  of  the  window.  Now,  use 
the  arrows  to  point  In  the  direction  you  want  the  window  frame  to  move. 
With  the  window  expand  key  the  edge  of  the  window  frame  on  the  same  side 
as  the  depressed  arrow  moves  in  the  direction  of  the  arrow;  while  using  the 
window  retract  key,  it  is  the  side  opposite  the  depressed  arrow  which  moves 
in  the  direction  of  the  arrow.  Figure  7  will  help  you  visualize  how  to  use 
the  arrows  for  these  commands.  The  window  cannot  be  retracted  completely: 
part  of  the  window  must  always  be  visible.  To  indicate  to  Screenwriter  that 
you  have  changed  the  size  of  the  window  as  much  as  you  wanted,  press 


the  accept  key  or  any  other  non-arrow  key.  While  you  are  changing  the 
size  of  a  window,  the  last  line  of  the  screen  will  say  ‘CHANGE  WINDOW 
SIZE— USE  ARROWS'. 
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FIG.  UM-7  —  Window  Changes 


Changing  the  location  of  a  window  Is  similar  to  changing  the  size. 
The  rule  to  remember  here  Is,  obviously  the  window  must  remain  on  the  area 
of  the  tabletop.  To  move  the  window:  position  the  cursor,  depress  move 
window  and  use  the  arrow  keys.  The  window  will  move  around  the  tabletop 
in  the  direction  indicated  by  the  arrows  that  are  depressed.  To  conclude 
this  command,  push  accept  or  any  other  non-arrow  key.  Again,  Screenwriter 
will  remind  you  by  putting  ‘MOVE  WINDOW — USE  ARROWS'  in  the  last  line 
of  the  screen. 

Finally,  the  content  of  the  window  (l.e.  what  you  see  In  the  window) 
can  be  easily  changed.  Just  as  you  can  cause  Screenwriter  to  scroll  (up 
or  down)  and  ad|ust  (left  or  right)  the  tabletop  in  the  screen,  you  also  can 
cause  the  document  being  projected  to  a  window  to  scroll  or  adjust  in  the 
window.  This  will  have  the  result  of  changing  the  area  of  the  document  which 
is  visible  through  the  window.  The  requirement,  of  course,  will  be  to  keep 
the  projection  camera  focused  on  some  part  of  the  document  paper;  that 
Is.  what  shows  through  the  window  must  always  be  part  of  the  same  document. 
Once  again,  the  cursor  position  at  the  instant  the  scroll  document  key  is 
pushed  will  select  the  window.  The  arrows,  page  up.  page  down,  top  and 
bottom  will  cause  the  projection  camera  to  move  in  the  direction  indicated. 
As  before,  the  accept  or  other  non-arrow  key  will  end  this  command. 
Screenwriter  will  indicate  the  command  he  is  performing  by  placing  the  words 
"SCROLL  OR  ADJUST — USE  ARROWS"  on  the  last  line  on  the  screen. 


The  Projection  Strength. 

As  noted  earlier,  projection  strength  decreases  with  age.  That  is. 
newer  projections  will  overlay  (hide)  older  projections.  There  may  be  times 
when  this  causes  some  difficulty  because  a  more  Important  document  gets 
hidden  by  a  document  of  less  Importance.  To  correct  just  such  a  situation 
there  is  a  command  which  will  swap  the  projection  strengths  of  two  projections 
on  the  tabletop.  Since  the  only  time  that  projection  strength  is  important 
is  when  hiding  occurs,  that  will  be  the  only  time  the  swap  strength  command 
will  be  effective.  To  use  the  command,  first  move  the  cursor  to  point  to 
a  spot  where  one  window  covers  another.  Now.  press  the  swap  strength 
key.  The  result  of  this  command  Is  that  the  window  which  was  previously 
hidden  in  the  area  of  the  cursor  is  visible  and  the  previously  visible  window 
is  hidden.  This  swapping  changes  the  strength  of  both  entire  windows;  so. 
as  a  consequence,  some  other  documents  may  partially  disappear  or  become 
visible.  (See  fig.  8.)  (Note  that  if  more  than  one  document  is  hidden,  the 
swap  strength  command  will  uncover  only  the  strongest  of  the  hidden 
documents.) 
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FIG.  UM-8  —  Swapping  Projection  Strength 


You  may  at  times  have  noticed  some  automatic  strength  swapping 
or  tabletop  scrolling  and  adjustment.  This  is  how  Screenwriter  ensures  that 


part  of  a  window  that  you  need  to  see  to  finish  a  command  is  visible  to 
you.  This  is  called  disclosure  and  was  first  seen  when  Screenwriter 
automatically  scrolled  up  the  screen  page  as  you  added  more  lines  to  the 
document  you  were  creating.  The  commands  move,  retract,  and  the  character 
or  arrow  keys  are  those  which  can  possibly  cause  disclosure. 
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FIG.  UM-9  —  Disclosure 


The  Window  Removal. 

Once  a  projected  document  is  complete  and  it  is  no  longer  needed 
on  the  screen,  it  can  be  easily  deleted  with  the  window  remove  key.  The 
window  to  be  removed  must  contain  the  cursor  at  the  time  this  key  is  pressed. 
The  result  of  this  action  is  to  change  the  appearance  of  the  tabletop  by  totally 
removing  the  designated  window.  The  document  in  the  filing  cabinet  is  not 
removed. 


In  the  first  chapter  we  learned  how  to  use  Screenwriter  to  create, 
correct,  print,  throw  away,  and  file  documents.  In  this  chapter  we  learned 
to  retrieve  documents  which  have  been  filed  by  projecting  them  from  the  filing 
cabinet  to  windows  on  the  tabletop.  We  also  now  know  how  to  change  the 
window  size,  location,  and  content  to  suit  our  needs.  We  can  change  the 
relationship  between  two  overlapping  windows  by  swapping  their  strengths. 

,  And  finally,  we  can  scroll  the  tabletop  up  and  down  or  adjust  it  left  and  right 

in  order  to  display  on  the  screen  exactly  that  portion  of  the  tabletop  which 
Is  currently  of  interest  to  us.  With  all  of  this  flexibility  now  at  our  command. 

»  we  are  prepared  to  learn  how  to  change  any  document  in  the  filing  cabinet 

that  is  visible  in  a  window.  (Remember,  up  to  this  point  we  have  been  able 
to  correct  only  those  documents  which  were  created  but  not  yet  filed.) 

3.  Uke  a  Bridge  Over  Troubled  Water... 

It  would  certainly  be  painful  to  have  to  start  completely  over  on  a 
document  if  we  found  an  error  in  it  after  filing  it  initially.  Sounds  like  the 
problem  of  trying  to  correct  something  after  removing  It  from  the  carriage 
of  your  typewriter,  doesn't  it)  Fortunately,  Screenwriter  is  much  too  flexible 
to  allow  that  sort  of  a  problem.  Much  of  the  correction  capability  is  not  new. 
but  Is  the  same  capability  that  you  had  when  Initially  creating  the  document 
(l.e.  when  the  document  was  still  in  the  typewriter  carriage.)  That  includes 
the  ability  to  change  characters,  insert  characters  and  delete  characters. 
In  addition,  some  new.  more  powerful  line  insertion  and  deletion  commands 
can  be  included  in  your  tool  box  with  only  a  very  brief  further  explanation 
of  projections. 

*  Before  we  discuss  these  document  changing  commands  in  greater 

detail,  it  is  important  that  you  understand  the  effect  such  commands  will  have 
in  general.  Earlier,  when  we  were  creating  and  correcting  documents,  we 
used  a  blank  sheet  of  paper  which  expanded  to  be  as  long  as  necessary 
to  hold  one  document.  Now.  we  realize  that  the  sheet  of  paper  was  simply 
part  of  the  tabletop,  and  that  corrections  were  being  made  to  the  tabletop 
itself.  With  the  documents  no  longer  part  of  the  tabletop  but  Instead  filed 
away  In  the  filing  cabinet  and  only  their  projections  visible  on  the  tabletop, 
what  will  the  corrections  actually  change?  The  answer  is  quite  simply  that 
the  corrections  we  will  discuss  In  just  a  moment  will  still  correct  the  document. 


While  that  may  seem  a  little  strange  at  first,  you  will  soon  realize  how  useful 
It  is  to  be  able  to  change  a  document  by  working  on  a  picture  of  It  that 
you  have  placed  In  a  window  on  the  tabletop.  However,  one  Important 
consequence  of  this  must  be  emphasized:  projections  always  show  what  is 
on  the  filed  document;  If  that  document  is  changed,  then  the  picture  of  the 
document  seen  In  a  window  will  have  also  changed.  Or.  put  another  way. 
if  the  same  part  of  a  document  Is  projected  to  two  different  windows  and 
the  document  is  changed  through  one  of  these  windows,  then  the  same 
changes  will  also  be  seen  In  the  second  window. 

The  Document  Corrections  And  Printing  Revisited. 

In  the  first  chapter  of  this  tour  of  Screenwriter,  we  encountered  some 
techniques  for  correcting,  removing,  or  printing  a  document  that  was  being 
created.  The  character  keys.  Insert,  delete,  print,  and  throw  away  were  used 
to  accomplish  this  manipulation  of  the  new  (not  yet  filed)  document.  These 
same  keys  can  now  be  used  to  manipulate  documents  In  the  filing  cabinet 
whose  projections  are  visible  In  windows  on  the  screen. 

For  example,  typing  character  keys  in  a  window  will  change  the 
characters  seen  in  the  window,  because  it  changes  the  document  which  Is 
being  projected  to  that  window.  Even  the  name  line  can  be  changed  in  this 
way.  Just  as  the  character  keys  would  not  force  the  cursor  off  the  document 
before,  neither  will  they  force  the  cursor  out  of  the  window  frame  now.  The 
size  of  your  window,  therefore,  will  determine  the  current  margins  for  all 
changes  and  additions  you  make  with  the  character  keys.  (Note  that  the 
window  will  not  affect  the  line  width  of  text  previously  created  with  different 
margins.)  Although  not  mentioned  earlier,  a  document  being  created  Is  in 
a  window  of  Its  own  and.  therefore,  margins  can  be  set  during  document 
creation  In  this  exact  same  manner  (eg.  with  window  retract  or  expand). 

To  add  characters  to  existing  lines  or  to  create  new  lines  in  the 
projected  document  can  be  done  as  before  with  the  Insert  command.  In 
this  case,  the  Screenwriter  will  only  allow  insertions  which  do  not  force  the 
end  of  the  line  beyond  the  edge  of  the  current  window  frame  (margin). 

Delete  also  has  the  same  effect  as  before.  Deleting  a  carriage  return 
will  only  work  if  the  two  lines  being  joined  will  still  fit  in  the  margins  defined 
by  the  window. 

The  throw  away  key  is  just  as  dangerous  as  before  because  it  will 
also  cause  a  document  which  has  been  filed  to  be  removed  from  the  file 


and  placed  in  the  waste  bin.  To  choose  a  document  to  be  thrown  away, 
place  the  cursor  in  its  window  or  its  home  picture  name  line  and  press  the 
throw  away  key.  When  this  command  is  complete.  Screenwriter  will  also  have 
eliminated  ail  projections  whose  cameras  or  projectors  were  over  the  deleted 
document  and  its  name  line  will  no  longer  appear  on  the  home  picture. 

Finally,  the  print  command  can  now  be  described  In  its  more  general 
form.  When  the  print  key  Is  pushed,  the  cursor  could  be  In  any  of  three 
possible  positions  giving  three  different  printed  results.  The  first  possibility 
is  that  the  cursor  is  in  a  name  line  In  the  home  picture.  In  which  case  the 
whole  document  represented  by  the  name  line  will  be  printed  as  it  exists 
In  the  filing  cabinet.  The  second  cursor  position  Is  In  a  name  line  of  a 
projection  while  not  In  the  home  picture.  This  would  cause  the  contents 
of  that  entire  window  to  be  printed.  The  final  case  is  when  the  cursor  is 
not  In  a  name  line.  This  causes  the  picture  area  (ie.  that  which  can  be 
seen  on  the  screen)  to  be  printed. 

As  you  see.  these  document  correction,  printing,  and  removal 
commands  have  not  changed  from  the  way  they  were  originally  introduced, 
but  have  merely  become  more  general  since  they  now  also  work  for  documents 
which  have  been  filed  in  the  filing  cabinet  and  projected  back  to  the  tabletop. 

The  Stained  Glass. 

Before  we  introduce  the  new  document  changing  commands  which 
deal  with  lines  of  a  document  rather  than  single  characters,  we  need  some 
method  of  pointing  to  a  group  of  lines  that  are  visible  in  a  projection  window. 
This  is  done  by  coloring  one  of  the  panes  of  the  window  to  highlight  the 
pan  of  the  document  seen  through  that  pane.  In  many  respects  this 
highlighted  area  will  behave  like  a  'window  in  a  window.*  The  methods  for 
creating,  expanding,  retracting,  moving,  and  deleting  a  pane  of  stained  glass 
are  similar  to  the  equivalent  methods  used  for  windows  themselves.  The 
stained  glass  pane  must  be  totally  within  the  frame  of  a  single  window  just 
as  the  window  must  stay  on  the  tabletop.  Perhaps  the  simplest  method  of 
thinking  about  the  stained  glass  is  to  imagine  a  colored  filter  which  has  been 
placed  over  part  of  the  lens  of  the  projector  which  is  projecting  into  the 
window  frame. 
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FIG.  UM-10  —  The  Stained  Glass 

To  create  a  stained  glass  window  pane,  scroll  the  tabletop  until  no 
area  of  the  window  which  Is  above  or  left  of  the  intended  pane  is  visible 
on  the  screen.  Then,  move  the  cursor  until  it  Is  In  the  lower  right  corner 
of  the  intended  pane.  (Note  how  similar  this  is  to  the  way  you  identified 
a  window  area  —  the  only  difference  is  that  the  pane  must  be  totally  within 
the  window  area.)  Finally,  press  the  stained  glass  create  key  and  watch  the 
area  you  have  indentified  turn  to  reverse  video  (black  on  white)  like  the  name 
line.  If  instead  of  a  small  stained  glass  pane  you  want  the  entire  window 
to  be  stained  glass,  then  place  the  cursor  in  the  name  line  shown  in  the 
window  and  press  the  stained  glass  create  key. 

Stained  glass  expand,  retract,  move,  and  remove  work  as  described 
for  the  window  commands  of  the  same  name  (once  again  remembering  that 
the  stained  glass  pane  must  stay  in  the  window.) 

The  Scissors  and  Glue. 


Have  you  ever  wanted  to  snip  a  few  lines  or  a  paragraph  out  of  a 
document  or  get  out  your  glue  and  add  a  new  paragraph  to  your  document? 
Screenwriter  will  help  you  do  both  of  these  document  updating  tasks.  For 


all  o<  the  document  updating  commands  (cut,  paste,  and  paste&cut)  you  will 
create  a  stained  glass  pane  to  indicate  the  lines  that  you  wish  to  move  or 
remove.  The  window  will  be  selected  by  the  cursor  position  at  the  time  the 
command  key  is  depressed.  Any  lines  in  the  window  which  are  even  partially 
colored  by  the  stained  glass  will  be  included  in  the  area  to  cut  or  pasted. 
A  strong  word  of  warning  should  be  issued  here:  know  what  part  of  your 
window  is  in  stained  glass  before  you  use  one  of  these  commands  —  the 
entire  pane  of  the  stained  glass  will  be  used  as  a  line  selection  device 
regardless  of  whether  or  not  you  can  currently  see  the  entire  pane. 

The  cut  key  will  remove  from  a  document  all  lines  which  are  partially 
covered  by  the  stained  glass  In  the  window  selected  by  the  cursor.  A 
document  can  not  be  completely  removed  In  this  manner  because  the  name 
line  can  not  be  snipped  away.  Of  course,  any  gap  created  In  the  document 
by  the  cut  command  is'  immediately  closed  by  Screenwriter  who  will  join  the 
two  parts  back  together. 

The  paste  command  requires  two  keys.  First,  the  paste  key  will  cause 
Screenwriter  to  copy  all  the  lines  which  are  partially  covered  by  the  stained 
glass  in  the  window  selected  by  the  cursor.  These  copied  lines  will  then 
be  inserted  In  the  place  you  choose.  To  choose  a  receiving  location,  position 
the  cursor  in  the  line  of  the  receiving  document  immediately  above  where 

the  new  lines  are  to  be  inserted.  The  accept  command  will  complete  the 

action  by  pasting  the  lines  Into  the  selected  location.  After  you  depress  the 
paste  key.  Screenwriter  will  remind  you  that  it  is  waiting  to  paste  in  the  copied 
lines  with  -PASTING— POSITION  WITH  ARROWS.  END  WITH  ACCEPT’  on  the 
last  line  of  your  screen. 

The  paste&cut  key  does  exactly  the  same  as  the  paste  followed  by 

the  cut.  The  effect  Is  to  transfer  lines  of  a  document  rather  than  just  copy 

them  as  is  done  with  the  paste  command.  Like  the  paste  command,  paste&cut 
is  terminated  with  the  accept  command. 

This  chapter  has  taken  us  through  a  review  of  the  keys  which  are 
useful  for  document  correction;  like  the  character  keys,  insert,  delete,  and 
throw  away.  Then  we  found  the  secret  of  highlighting  part  of  a  window  by 
putting  in  stained  glass.  With  this  method  of  selecting  lines  from  a  document, 
we  found  some  stronger  document  updating  techniques  in  cut,  paste,  and 
paste&cut.  However,  this  does  not  complete  the  tool  kit  that  Screenwriter 
gives  you  for  handling  documents.  The  next  chapter  outlines  the  final  tool. 


4.  Deja  Vu... 


Screenwriter  as  you  currently  know  it,  is  certainty  a  powerful  warrior 
in  the  ’paper  war*.  But.  the  power  does  not  end  here;  indeed,  the  best 
is  yet  to  come.  To  study  the  final  capability  available  in  Screenwriter  for 
dealing  with  documents  we  need  to  solve  the  riddle;  'How  can  part  of  one 
document  actually  be  part  of  a  different  document?* 

The  Projections  —  Yet  Again. 

The  answer  to  the  above  riddle  Is  similar  to  an  answer  we  used  to 
solve  another  problem  earlier.  Projecting  text  from  one  document  to  another 
will  cause  the  shared  information  to  exist  in  both  documents.  A  quick  review 
of  projections  will  show. that  there  is  an  even  greater  advantage  to  projecting 
text  from  one  document  to  another.  (After  all.  paste  already  allows  us  to 
copy  text  from  one  document  to  another.) 

Recall  that  a  projection  involves  a  camera  which  sees  part  of  one 
document  and  transmits  what  it  sees  to  a  projector  which  projects  that  same 
picture  onto  a  document.  (If  you  have  come  to  the  conclusion  at  this  point 
that  the  tabletop  Is  Just  a  large  document,  you  are  absolutely  right.)  Both 
the  area  seen  and  the  area  projected  to  must  be  on  an  existing  area  of 
a  document.  The  strength  of  a  projection  depends  on  how  recently  it  was 
created  (i.e.  new  Is  strong,  old  is  weak)  and  the  relative  projection  strengths 
determine  what  Is  visible  in  an  area  where  two  or  more  projections  overlap. 
The  final  attribute  of  projections  to  remember  is  that  any  change  made  to 
the  area  of  the  document  seen  by  the  camera  will  also  be  seen  on  the 
document  that  is  projected  onto.  That  is.  by  changing  the  original  you  also 
change  all  projected  images  of  that  original.  It  Is  this  last  attribute  that  makes 
projections  such  a  useful  tool  In  the  building  of  documents.  As  an  example, 
consider  the  possibilities  where  an  address  or  telephone  number  changes. 
If  you  projected  the  address  (or  telephone  number)  rather  than  copying  it 
whenever  it  was  required  on  a  document,  then  a  single  change  to  the  original 
address  or  telephone  number  would  correct  all  occurrences  of  it  in  you r  file 
of  documents. 

Two  commands,  using  four  keys,  will  allow  you  to  utilize  the  power 
of  document  building  projections.  Document  building  projections  are  projections 
which  do  not  involve  the  tabletop,  but  rather,  involve  only  documents  in  the 
filing  cabinet.  (Of  course,  you  already  know  about  the  commands  which  create 


and  control  viewing  projections,  that  Is  projections  which  cause  documents 
to  appear  in  windows  on  the  tabletop.)  The  first  command  is  document 
building  projection  create;  it  requires  that  both  ends  of  the  projection  have 
been  defined.  The  area  to  be  placed  under  the  projection  camera  Is 
designated  by  the  stained  glass  pane  in  the  window  pointed  to  by  the  cursor 
when  the  camera  here  key  is  depressed.  The  projections  will  be  put  in  the 
area  of  the  appropriate  size  whose  upper  left  corner  is  defined  by  the  cursor 
position  at  the  moment  the  prolector  here  key  Is  pushed.  Once  the  camera 
and  projector  position  have  been  determined  in  this  manner,  the  create  key 
will  create  the  projection  and  the  effect  will  be  Immediately  seen  on  the 
document  under  the  projector.  Whereas  the  paste  command  will  add  a 
number  of  whole  lines  to  a  document,  creating  a  projection  covers  part  of 
a  document  which  already  exists  and  is  not  at  all  confined  to  whole  lines. 
After  the  camera  or  projector  positions  have  been  selected,  either  can  be 
changed  without  disturbing  the  other  In  order  to  create  a  different  projection. 
The  only  requirement  is  the  areas  selected  must  still  exist  in  the  documents 
when  the  create  key  Is  activated. 


DOCUMENT  2  IS  BUILT  FROM  INFORMATION 

'shared'  from  other  documents 
FIG.  (JM-11  —  Document  Building  Projections 

Perhaps  some  examples  are  required  here.  Suppose  one  of  your 
documents  is  an  address  list  of  clients  and  that  another  is  a  form  tetter  to 
be  printed  and  sent  to  each  client.  In  this  case  you  would  certainly  want 
the  area  seen  by  the  camera  to  change  to  a  new  address  before  each 
projection  was  created.  However,  the  area  of  the  form  letter  (inside  address 


area)  to  receive  the  projections  would  not  change.  Suppose,  on  the  other 
hand,  that  you  had  created  a  revised  paragraph  to  replace  a  paragraph 
currently  in  a  number  of  contracts  filed  by  Screenwriter,  in  this  case  the 
camera  would  stay  positioned  over  the  revised  paragraph  while  you  would 
position  the  projectors  over  the  approprate  part  of  the  various  contracts. 

The  final  command  for  use  on  document  building  projections  is 
remove.  To  remove  a  projection,  place  the  cursor  In  the  area  being  projected 
onto  and  push  remove.  In  the  area  pointed  to  by  the  cursor  you  will 
immediately  see  whatever  was  on  the  document  but  had  been  hidden  by  the 
projection  just  deleted. 

it  is  important  to  note  here  that  the  commands  insert,  delete,  paste. 
cut,  and  paste&cut  will  not  work  on  lines  which  Include  text  that  has  been 
projected  onto  them  in  the  manner  just  described.  The  reason  for  this  is 
that  the  text  being  projected  can  not  be  moved  or  removed  except  by  changing 
the  projection  or  by  changing  the  text  under  the  camera.  The  text  being 
projected  can  not  be  altered  by  changing  the  area  onto  which  it  is  projected. 
The  throw  away  command  will  cause  Screenwriter  to  remove  any  building 
projections  from  or  onto  the  document  to  be  deleted. 

Before  leaving  document  building  projections  behind,  let's  look  at  a 
couple  of  questions  that  may  have  occurred  to  you  as  you  read  this  last 
chapter.  For  example,  you  might  well  be  thinking:  "When  do  I  use  a  viewing 
projection  Instead  of  a  document  building  projection?"  The  answer  is,  anytime 
you  wish  to  see  a  document  part  on  the  screen  or  wish  to  make  changes 
(including  new  document  building  projections)  to  a  document,  then  the 
document  must  first  be  projected  to  the  tabletop  with  a  viewing  projection, 
if  you  wish  to  have  the  exact  same  text  in  two  different  document  areas  so 
that  changes  to  one  will  be  reflected  in  the  other,  then  create  a  document 
building  projection. 

You  may  also  have  wondered:  "Why  can  document  building  projections 
not  be  moved,  or  changed  in  size  or  content  like  viewing  projections?"  The 
answer  to  this  Is  the  different  intent  of  the  two  types  of  projections.  Document 
building  projections  are  not  likely  to  change  while  viewing  projections  are 
almost  certain  to  change.  If  for  some  reason  a  document  building  projection 
must  be  changed,  then  It  should  be  removed  and  recreated  as  required. 

Another  question  that  may  have  come  to  mind  is:  "if  I  make  a  change 
to  a  document  (say  replace  one  character  by  another),  then  what  affect  does 
that  change  have  on  other  documents  in  the  filing  cabinet  and  the  tabletop?" 


This  is  an  easy  but  important  question  to  answer.  Any  projection  (viewing 
or  document  building)  whose  projection  camera  sees  the  area  of  the  document 
which  has  been  changed  will  project  that  change  (to  the  tabletop  or  the 
receiving  document.)  In  the  case  of  the  document  building  projection,  the 
document  receiving  the  projection  will  be  changed  and  the  whole  process 
is  repeated  If  the  changed  area  of  this  document  Is  under  a  projection 
camera.  Hence,  with  the  proper  projections,  it  Is  possible  for  a  single  change 
to  be  reflected  in  any  number  of  documents  and  in  any  number  of  windows 
on  the  tabletop. 

5.  To  err  Is  human... 


it  is  quite  likely' that  at  some  time  you  are  going  to  accidently  press 
the  wrong  key  or  change  your  mind  after  you  see  the  result  of  the  action 
you  have  just  taken.  Screenwriter  has  provided  for  such  eventualities  by 
providing  a  single  reverse  key  to  undo  what  you  have  just  done.  Reverse 
Is  limited  to  undoing  the  immediately  preceding  command.  Therefore,  as 
soon  as  a  new  reversible  key  is  activated,  it  becomes  too  late  to  reverse 
the  effects  of  a  previous  key.  There  are.  however,  some  keys  which,  because 
of  their  simplicity  to  correct  by  other  means,  are  Ignored  by  the  reverse  key. 
These  keys  are: 

1.  all  character  keys  and  return 

2.  the  arrow  keys,  page  up.  page  down,  top,  and  bottom 

3.  accept 

4.  delete 

5.  print 

6.  reverse 

7.  quit 

That  is.  any  one  of  the  other  special  Screenwriter  command  keys  can  be 
reversed  if  it  is  the  most  recently  activated  of  these  keys.  Reversing  the 
home  key  returns  the  screen  to  its  position  at  the  moment  when  the  home 
key  was  depressed.  Multiple  key  commands  (eg.  those  using  arrows  to  give 
direction)  are  reversed  completely  —  thereby  reversing  the  effects  of  the 
entire  command. 


It  should  also  be  obvious  that  reverse  Is  not  the  only  way  to  undo 
actions  you  have  commanded  Screenwriter  to  perform.  If  you  look  once  again 
to  fig.  1  which  shows  the  keyboard  arrangement,  you  will  note  that  the  lowest 
level  of  special  Screenwriter  command  keys  includes  only  keys  which  cause 
movement,  size  change  and  character  insert/delete  (and  printing).  Any  of 
these  commands  (except  print)  can  be  easily  undone  with  one  of  the 
commands  from  the  same  level  and  often  by  using  the  same  command  In 
the  opposite  direction.  Of  course,  this  type  of  change  can  be  done  at  any 
time  and  is.  therefore,  more  general  than  reverse.  The  middle  level  of  special 
command  keys  are  mainly  the  create  keys  and  can  easily  be  undone  with 
the  upper  level  destruction  keys.  The  destruction  keys,  of  course,  are  much 
more  difficult  to  undo  than  the  other  keys.  Often,  the  alternative  to  the  reverse 
key  for  undoing  the  effects  of  a  destruction  key  Is  the  complete  recreation 
of  the  object  (eg.  document,  window,  stained  glass  pane,  or  projection)  which 
was  destroyed.  The  top  level  of  special  command  keys,  consequently,  must 
be  used  with  caution.  This  is  why  each  one  requires  the  auxiliary  key  to 
also  be  depressed,  and  why  Screenwriter  may  question  your  desires  even 
further.  Note  that  the  only  way  to  reverse  the  effect  of  the  quit  key  is  to 
reactivate  Screenwriter. 

We  always  hope  never  to  made  a  mistake  and  push  the  wrong  key. 
but  if  It  happens.  Screenwriter  will  usually  help  you  correct  the  error  if  you 
simply  tell  It  to  reverse  the  key. 

6.  And  to  all  a  good  night... 

The  capabilities  of  Screenwriter  have  now  all  been  explained  and  so 
all  that  remains  Is  to  clean  up  the  tabletop  and  ensure  that  the  documents 
are  safe  and  secure  in  the  filing  cabinet.  The  clean  up  key  will  cause 
Screenwriter  to  do  this  for  you.  Since  this  is  a  destructive  command. 
Screenwriter  will  ask  you  permission  to  carry  out  the  command  by  asking: 
'SHALL  I  CLEAR  THE  TABLETOP?'  If  you  reply  by  depressing  the  "Y*  key 
then  Screenwriter  will  remove  all  windows  from  the  tabletop  and  send  you 
to  the  home  picture. 

The  quit  command  stores  away  all  projections  and  documents  so  that 
the  next  time  you  activate  Screenwriter  you  will  be  able  to  begin  work  where 


CHAPTER  V 


The  Detailed  Baseline 

included  here  from  the  detailed  baseline  documentation  Is  the  final 
portion  of  the  formal  design  specification  and  the  system  implementation  plan. 
A  partial  Implementation  based  on  this  specification  and  implementation  plan 
has  been  accomplished,  but  will  not  appear  In  this  volume. 


FILER4 


Basis: 

Prior:  FILER3 

Forward:  FILING  CABINET4.1  /  PROJSET4.2  /  DISPLAY4.3 

Comments: 

This  level  decreases  the  specification  to  include  only  the  family  of 
systems  with  rectangular  and  finite  components  such  as  projection  slaves  and 
masters,  areas  of  filter  application,  documents,  and  the  display  (screen). 

The  decision  to  require  these  components  be  rectangular  in  area  is 
not  as  restrictive  as  might  first  be  imagined.  Nearly  ail  documents  (from 
margin  to  margin )  and  screens  are.  by  their  very  nature,  rectangular.  With 
this  in  mind,  consider  the  types  of  information  In  this  mainly  textual  system 
which  the  user  is  likely  to  project  or  filter.  He  might  project  a  speck,  a 
word,  a  ling,  a  paragraph,  a  page,  a  document,  or  some  multiple  of  one 
of  these.  Obviously,  in  our  rectangular  coordinate  system  a  speck  (and 
hence  also  a  word)  is  rectangular.  Now.  if  we  consider  a  document  as 
rectangular  from  margin  to  margin,  then  the  rectangular  lines  must  be 
constant  length  within  a  document.  Paragraphs  and  pages  (each  a  series  of 
consecutive  lines )  would  also  be  rectangular.  Any  information  of  a  less  normal 
shape  which  the  user  might  wish  to  project  or  filter  could  easily  be  described 
as  a  combination  of  these  basic  rectangular  objects. 

Additionally,  it  makes  sense  to  require  that  there  be  an  even  slightly 
more  rigid  connection  between  the  shape  of  a  slave  and  its  master  than  a 
shared  rectangularly.  Since  It  Is  unlikely  that  a  user  would  wish  to  respell 
a  word  (le.  mix  letters  of  the  word)  as  it  is  being  projected,  for  example, 
the  relative  position  of  each  point  in  a  slave  should  be  the  same  as  the 
corresponding  master  point  relative  position  in  the  master.  This  means  that 
the  projection  is  not  only  rectangular  on  both  ends,  but  that  the  two  rectangles 
are  equivalent  in  size  and  shape,  with  projections  going  between 
corresponding  positions  within  the  rectangular  areas.  This  same  equivalence 
relationship  should  also  be  true  between  the  screen  area  and  the  area  of 
document  seen  on  the  screen. 

The  requirement  that  the  parts  of  the  system  be  finite  is  not 
significantly  restrictive  to  the  system  since  we  are  using  a  discrete  (integer) 
coordinate  space. 


FILING  CABINET4.1 


Basis: 

Prior:  FILING  CABINET!.  1  /  FILING  CABINET3.1 

Comments: 

The  documents  In  the  filing  cabinet  are  rectangular  in  shape  and 
must  be  finite  In  size. 

Requirements  /  Design  Decisions: 

1 1  ]|  All  documents  must  be  finite  and  rectangular  (that  is.  all  lines  are  a 
constant  length). 

(21  For  simplicity,  all  documents  must  start  in  coordinate  (1.1).  This  in 
no  way  limits  the  document  but  does  facilitate  the  system  specification. 

Auxiliary  Definitions: 

We  can  now  define  the  meaning  of  being  rectangular.  We  know  that 
a  rectangle  is  always  uniquely  defined  by  its  diagonal.  Therefore,  we  define 
a  pair  of  functions  to  find  the  smallest  and  the  biggest  of  a  finite  set  of 
coordinates. 

a. 

smallest, 

biggest  :  F1  (coordinate)  — >  coordinate 
smallest  (S)  a  p(c  :  S  |  (Va  :  S)  (c  <  a)) 
biggest  (S)  a  p(c  :  3  I  (Va  :  S)  (c  >  a)) 

The  smallest  coordinate  is  the  leftmost  coordinate  in  the  top  row 
of  coordinates.  The  biggest  coordinate  is  the  rightmost  coordinate  in  the 
bottom  row  of  coordinates.  These  definitions  are  consistent  with  our 
lexicographical  orderings  <  and  >. 

Now.  determine  which  coordinates  a  rectangle  defined  by  the  smallest 
and  the  biggest  coordinate  should  include. 


area  :  coordinate  x  coordinate  — »  P  (coordinate) 
area  a  (Xa,b) 

(x(a)..x(b))  *  (y(a) . .y(b) ) 

This  defines  the  set  of  coordinates  which  is  rectangular  based  on 
given  smallest  and  biggest  coordinates. 


is-rectangle  :  JP  (coordinate)  —>  boolean 
is-rectangle  a  (XC) 

C  *  ft  =>  area  (smallest  (C)  fbiggest(C) )  -  C 

An  empty  set  of  coordinates  is  rectangular  by  definition.  Any  other 
set  of  coordinates  is  rectangular  if  it  includes  only  the  coordinates  in  the 
rectangular  area  defined  by  the  biggest  and  smallest  (ie.  the  diagonal) 
of  the  given  set. 

State  Component  Definition: 

FILING  CABINET4.) _ 

FILING  CABINET1.1 


(Vx  :  dom  (documents)) 

(is-rectangle  (dom  (documents  (x)))  a 
dom  (documents  (x))  €  F  (coordinate)  a 
smallest  (documents  (x))  -  (1,1)) 


PR0JSET4.2 

Basis: 

Prior:  PROJSET3.2  /  FILING  CABINET4.1  (Auxiliary  Definitions) 

Comments: 

The  slave  and  master  of  all  projections  must  be  rectangular,  finite. 
equivalent  areas.  The  area  transformed  by  any  non-identity  filter  in  a 
projection  must  also  be  rectangular.  These  are  reasonable  restrictions 
because  we  commonly  work  with  only  rectangular  areas  of  text.  This 
specification  restricts  the  PROJSET2  appropriately  to  enforce  these 
requirements. 

Requirements  /  Design  Decisions: 

|[  1 H  All  projection  slaves  and  masters  are  finite,  rectangular  areas. 

([2] |  The  slave  and  master  of  any  projection  are  equivalent  areas  in  size 
and  shape,  with  the  projection  defining  corresponding  positions  within  these 
areas.  Besides  ruling  out  scaling  and  skewing,  this  eliminates  any  arbitrary 
information  jumbling. 

([3])  Any  area  of  non-identity  fitter  application  within  a  projection  slave  area 
is  finite  and  rectangular. 

Auxiliary  Definitions: 

a. 

strip  :  P  (COORD)  — >  P  (coordinate) 
strip  a  ( XS) 

coord  (]  S  D 


This  reduces  a  set  of  COORD  to  a  set  of  coordinates  by  removing 
the  docname  from  each  COORD. 


is-eqshape 

is-eqshape 


projection  — >  boolean 
(XP) 

(3n) 

P  -  (Xc)  (c  +  n) 


This  constant  defines  the  concept  of  equivalent  areas  of  size  and 
shape  for  the  slave  and  master  of  a  projection.  Less  abstractly  we  could 
say  that  for  any  point  in  the  slave,  the  corresponding  point  in  the  master 
must  be  equal  to  the  difference  between  the  slave  coordinate  corresponding 
to  the  smallest  point  In  the  slave,  and  the  smallest  point  in  the  slave 
minus  the  given  slave  point.  In  other  words,  the  smallest  slave  point  and 
Its  corresponding  master  point  are  used  as  the  origins  of  the  two  areas  and 
all  other  coordinate  positions  are  computed  relative  to  these. 

State  Component  Definition: 

PROJSET4 . 2 _ 

PROJSET3 . 2 

(Vx  :  dom  (projlist)) 

I1J  ( is-rectangle  (strip  (dom  (projlist  (x))))  a 
dom  (projlist  (x))  c  F(COORD)  A 
|[3D  is-rectangle  (strip  (dom  (filterlist  (x) 

/  J(speck) ) ) ) 

A 

I2B  is-eqshape  (projlist  (x))) 


PROJSET3 . 2  is  restricted  as  required.  The  fact  that  the  domain 
of  a  projection  Is  finite  implies  that  the  range  of  that  projection  and  its 
associated  area  of  filter  application  are  also  finite.  If  the  slave  of  a  projection 
is  rectangular  and  the  master  is  the  same  shape,  then  it  is  obvious  that 
the  master  is  also  rectangular. 


DISPLAY4.3 


Basis: 

Prior:  DISPLAY3.3  /  FILING  CABINET4.2  (Auxiliary  Definitions) 

Comments: 

This  restricts  the  screen  to  a  rectangular  area  which  displays  a 
rectangular  area  of  the  chosen  document.  For  textual  displays,  this  is  a 
normal  restriction. 

Requirements  /  Design  Decisions: 

1 1 J  The  area  which  Is  displayed  on  the  screen  must  be  rectangular  and 
finite. 

State  Component  Definition: 

DISPLAY4 . 3 _ 

DISPLAY3 . 3 


[1]  is-rectangle  (strip  (seearea))  a 

seearea  e  F  (COORD) 


FILER4 


State  Definition: 

FILER4  a  FILER3 

(FILING  CABINET1.1  P-fr  FILING  CABINET4 . 1; 
PROJSET3 . 2  PROJSET4 . 2 ; 

DISPLAY3 . 3  H>  DISPLAY4 . 3 ) 

This  new  state  space  is  FILER3  with  the  accumulated  component 
restrictions  added. 


FILER4A 


Basis: 

Prior:  FILER4 

Forward:  FILING  CABINET4.1A  /  PROJSET4.2A  /  DISPLAY4.3A 

Comments: 

This  first  refinement  introduces  arrays  as  a  representation  of  tables 
and  functions.  This  representation  eases  the  specification  of  rectangular  while 
bringing  the  specification  closer  to  a  high  level  language  implementation. 

Additionally,  it  introduces  a  different  and  more  convenient  method  of 
defining  a  rectangular  area  of  coordinates  as  required  for  slaves,  masters, 
ares  of  filter  application,  and  the  area  visible  to  the  user.  A  finite  rectangular 
plane  can  be  fully  described  by  its  starting  point  (eg.  upper  left  corner)  and 
its  size  (eg.  the  length  of  its  diagonal.)  Although  this  is  not  the  only  possible 
representation  for  a  rectangular  plane,  it  has  the  desirable  feature  that 
compositional  operations  (see  FILER!)  can  be  specified  with  addition  and 
subtraction  of  coordinate  pairs. 


FILING  CABINET4.1A 


Basis: 

Library:  ARRAY 
Prior:  FILING  CABINET4.1 

Comments: 

The  use  of  a  table  (array)  is  a  common  and  well  understood  method 
for  storing  a  number  of  individual  pieces  of  information  (In  this  case  specks). 
It  is  also  useful  because  it  can  be  easily  defined  In  a  finite  rectangular  shape 
to  accommodate  previous  design  decisions.  Of  course,  high  level 
programming  languages  allow  the  declaration  of  arrays  so  this  step  puts  the 
specification  slightly  closer  to  the  eventual  implementation. 

Auxiliary  Definitions: 

a. 

DOCUMENTCLASS - 

table  :  ARRAY  [  speck  ] 

rows  :  JV 

cols  :  JV 


rows  -  length  (table) 

(Vx  :  l..rows)  (length  (table  (x))  -  cols) 


We  create  the  new  description  of  a  rectangular  document  using  an 
array.  This  array  will  be  a  table  of  specks  which  are  the  content  of 
the  document.  The  size  of  the  table  is  defined  by  rows  and  cols  which 
represent  the  number  of  rows  and  columns  in  the  table.  Of  course,  this 
makes  the  shape  of  the  table  rectangular  and  finite.  The  table  will 
correspond  to  the  extent  of  the  document  as  we  previously  defined  it: 
however,  there  is  no  restriction  from  allowing  part  of  the  background  paper 
(ie.  the  margins  of  the  document)  to  be  included  in  the  extent  If  we  choose 
to  define  it  that  way. 


b. 

retv-surface  :  DOCUMENTCLASS  — >  surface 
retv-surface  «  (XD) 

(Xc  |  (1,1)  >  c  >  (cols, rows)) 
table  (y  (c))  (x  (c)) 

Given  a  document  description  and  a  coordinate  In  the  extent  of  the 
document,  this  function  will  return  the  speck  which  appears  at  that  coordinate. 
The  proper  speck  is  generated  by  entering  the  table  at  the  row  and  column 
defined  by  the  coordinate.  This  function  causes  the  table  to  appear  as  if 
it  were  a  surface. 

State  Component  Definition: 

FILING  CABINET4.1A - 

FILING  CABINET4 . 1 

docdata  :  docname  -**  DOCUMENTCLASS 


dom  (documents)  -  dom  (docdata) 

(Vx  :  dom  (docdata)) 

(biggest  (dom  (documents  (x)))  -  (cols, rows)) 
(Vx  :  dom  (docdata)) 

(documents  (x)  -  retv-surface  (docdata  (x)) 


For  each  document,  there  is  an  table  which  is  accessible  by  the 
document's  name.  The  tables  are  exactly  the  same  size  as  the  extent 
of  the  corresponding  document  so  that  a  one  to  one  translation  between  the 
document  and  the  table  representing  it  is  easily  done.  Remember,  to  this 
point  the  only  design  decision  taken  about  documents  is  that  they  must  be 
finite  and  rectangular  —  conditions  which  are  obviously  enforced  by  this 
refinement. 

«**  Notice:  In  future  usage,  since  rows  and  cols  are  derived 
components,  we  will  use  the  abbreviation: 

docdata  (x) 
to  represent: 

table  (docdata  (x)) 


Basis: 


PROJSET4.2A 


Library:  FUNCTION 
Prior:  PROJSET4.2 

V 

Comments: 

When  two  related  areas  of  tables  are  to  be  equivalent  in  size  and 
shape,  the  easiest  description  possible  of  the  projection  relating  those  areas 
Is  two  starting  spots  and  a  size/shape  description.  And,  when  the  areas 
are  rectangular,  the  size/shape  description  is  simplified  to  a  pair  of  row  and 
column  size  values.  Similarly,  a  rectangular  filter  application  area  can  easily 
be  defined.  The  actual  filter  Is  a  total  function  which  is  also  described  by 
an  array. 

Auxiliary  Definitions: 


a. 

PRO J CLASS _ 

alavespot 

masterspot 

projsize 

atartpane 

paneaize 

f 


COORD 

COORD 

coordinate 
coordinate 
coordinate 
FUNCTION  [  apeck  1 


aread( atartpane, paneaize)  c 

aread( coord  (alavespot) , projsize) 

projsize  >  (0,0) 


panes ize  >  (0,0) 


Any  projection  between  rectangular  areas  on  rectangular  documents 
can  be  described  by  two  starting  points  (smallest  points  of  the  slave  and 


master)  and  a  size  denoted  by  the  number  of  rows  and  columns  Included 
in  the  projected  area.  The  single  rectangular  filter  application  area  Is 
described  by  a  starting  point  (smallest  point)  and  a  size.  Note  that  the 
first  predicate  requires  the  area  of  the  filter  application  to  be  completely  on 
the  slave  area.  The  filter  to  apply  in  the  specified  pane  (like  a  window 
pane)  area  Is  represented  in  the  form  of  an  array  with  two  rows  —  one 
row  for  the  domain  and  the  other  for  the  range  —  with  the  column  numbers 
acting  as  a  link  between  the  appropriate  members  of  each  row. 

b. 

aread  :  coordinate  *  coordinate  — >  P(coordinate) 
aread  (a,s)  -  area  (a,  a  +  s  -  (1,1)  ) 

This  simple  function  allows  the  creation  of  a  rectangular  area  from 
a  smallest  point  and  a  size  rather  than  a  smallest  and  a  biggest 
point. 

c. 

retv-projection  :  PROJ CLASS  — *  projection 
retv-projection  ® 

(VS) 

( it  COORD  |  dn  -  dn  (slavespot  (S))  a  coord  c  w) 
dn'  -  dn  (masterspot  (S)) 

coord'  -  coord  (masterspot  ( S ) )  +  coord  - 

coord  (slavespot  (S)) 

where 

w  -  aread  (coord  (slavespot  (S)),  projsize  (S)) 

Given  a  refined  projection  description,  any  coordinate  in  the  slave 
area  is  translated  to  a  coordinate  In  the  master  area  by  adding  the  vector 
from  the  slave  starting  point  and  the  given  coordinate,  to  the  master  starting 


retv-f ilter-apply  :  PROJCLASS  — *  filter-apply 
retv-f ilter-apply  *  (XS) 

((COORD  ->  (J  (speck)})  t  w)  0 

((COORD  ->  (retv-filter  (f  (S))})  t  z) 

where 

w  -  {c  :  COORD  |  dn  (c)  -  dn  (slavespot  (S))  a  coord  (c) 

e  ww} 

z  -  {d  :  COORD  |  dn  (d)  -  dn  (slavespot  ( S ) )  A  coord  (d) 

e  zz) 

ww  -  aread  (coord  (slavespot  (S),  projsize  (S)) 
zz  -  aread  (startpane  (S),  panesize(S)) 

and  retv-filter  :  FUNCTION  -»>  filter 
retv-filter  a  (XF) 

(Xs  :  speck) 

F  (2)  (F  (l)'1  (s)) 

Given  a  refined  filter-apply  description,  a  coordinate  In  the  filter 
application  area  of  the  slave  will  return  the  filter  represented  by  the 
FUNCTION,  while  a  coordinate  in  the  slave  area  but  outside  the  area  of  filter 
application  will  generate  the  Identity  function. 


State  Component  Definition: 


PROJSET4 . 2A _ 

PROJSET4 . 2 

projdata  :  SEQ  [  PROJCLASS  ] 


dom  (projdata)  -  dom  (projlist) 

(Vx  :  dom  (projdata)) 

(projli3t  (x)  -  retv-projection  (projdata  (x))  a 
(filterlist  (x)  -  retv-f ilter-apply  (projdata  (x))) 


It  is  obvious  here  that  the  previous  design  decisions  concerning  the 
size  and  shape  of  the  slaves,  masters,  and  areas  of  filter  application  are 
inherent  in  this  new  representation.  Indeed,  so  complete  and  accurate  is 
this  representation  of  PROJSET  that  all  previously  defined  restrictions  on  the 
state  are  implicit  in  this  new  state  representation. 


DISPLAY4.3A 


Basis: 

Prior:  DISPLAY4.3  /  PROJSET4.2A  (Auxiliary  Definitions) 

Comments: 

As  done  In  the  FILING  CABINET  and  PROJSET,  the  rectangular 
area  In  the  DISPLAY  is  decribed  by  a  starting  point  and  a  size  value. 

Auxiliary  Definitions: 


a. 


DISPLAYCLASS. 


screenstart 

screensize 


:  COORD 
:  coordinate 


screensize  >  (0,0) 


The  rectangular  screen  is  defined  by  a  starting  point  (smallest 
point)  and  a  size  denoting  the  number  of  columns  and  rows  on  the  screen. 


b. 

areadC  :  COORD  x  coordinate  — >  JP(COORD) 
areadC  (C,a)  -  (c  :  COORD  I  dn  (c)  -  dn  (C)  a 

coord  (c)  e  aread  (coord  (C),a)} 

This  function  creates  a  rectangular  area  on  a  specific  document  from 
the  smallest  point  of  the  area  on  the  document  and  the  size  of  the  intended 


retv-display  :  DISPLAYCLASS  ->  F( COORD) 
retv-display  a  (XD) 

areadC  (screenstart , screensize) 

The  three  dimensional  area  defining  function  is  used  to  derive  the 
screen  from  a  starting  point  and  a  size. 

State  Component  Definition: 

DISPLAY4 . 3A - 

DISPLAY4 . 3 
DISPLAYCLASS 


seearea  -  retv-display  (DISPLAYCLASS) 


FILER4A 

State  Definition: 

PILER4A  a  FILER4 

(PILING  CABINET4 . 1  H>  PILING  CABINET4. 1A; 
PR0JSET4 . 2  p-fr  PROJSET4.2A; 

DISPLAY4 . 3  DISPLAY4 . 3A) 

The  new  state  is  simply  a  combination  of  the  refined  state 


components. 


FILER5 


Basis: 

Prior:  FILER4A 

Forward:  FILING  CABINET5.1  /  PROJSET5.2  /  DISPLAYS. 3 

Comments: 

The  current  design  allows  the  user  to  specify  any  document  in  the 
filing  cabinet  as  the  document  he  wishes  to  view.  This  advancement  of  the 
design  will  restrict  the  user  to  viewing  one  specific,  permanent  document  in 
the  filing  cabinet  called  tabletop.  This  permanent  viewing  document  can 
be  most  easily  envisioned  as  a  flat  tabletop  on  which  various  documents  are 
arranged  (protected)  for  viewing.  As  before,  any  combination  of  the  other 
documents  in  the  filing  cabinet  can  be  seen:  but  now  the  proper  projections 
of  the  required  documents  to  the  tabletop  must  be  defined. 

Because  of  the  restriction  to  view  only  the  tabletop  document,  we 
can  distinguish  between  two  different  types  of  projections:  building  projections, 
which  share  Information  between  documents,  and  viewing  projections,  which 
define  the  screen  document.  Since  the  screen  appearance  will  be  directly 
derived  from  this  later  type  of  projection,  only  viewing  projections  will  ever 
need  filter  application  areas. 


FILING  CABINET5.1 


Basis: 

Prior:  FILING  CABINET4A 

I 

Comments: 

The  filing  cabinet  will  be  required  to  always  contain  the  document 
which  will  be  displayed  (in  part)  to  the  user.  This  document  Is  called  the 

m 

tabletop  because  it  is  similar  in  usage  to  a  tabletop  upon  which  papers 
have  been  arranged  by  the  user. 

|  Requirements  /  Design  Decisions: 

[I]}  The  screen  document  must  be  permanent  in  the  FILING  CABINET. 


Auxiliary  Definitions: 
a.  tabletop  €  docname 

Define  tabletop  to  be  a  member  of  the  abstract  set  of  allowable 
document  names. 

State  Component  Definition: 

.  FILING  CABINET5.I _ 

FILING  CABINET4.1A 

*  J1J  tabletop  e  dom  (docdata) 


The  FILING  CABINET  will 


always  contain  the  document  called 


tabletop. 


PRQJSET5.2 


Basis: 


Prior:  PROJSET4.2A 


Comments: 

This  level  of  the  PROJSET  specification  will  begin  to  differentiate 
between  two  different  types  of  projections  —  the  building  projections  and  the 
viewing  projections.  Since  the  user  only  sees  documents  arranged  on  the 
tabletop,  only  the  projections  to  the  tabletop  (viewing  projections)  ever 
need  to  have  a  filter.  Therefore,  we  can  specify  that  projections  which  do 
not  have  a  slave  on  the  tabletop  (building  projections)  will  not  have  a 
filter  area.  We  also  wish  to  eliminate  the  tabletop  as  a  projection  master 
because  doing  so  will  remove  the  possibility  of  unnecessary  circularity  without 
a  loss  of  capability. 

Requirements  /  Design  Decisions: 

[I])  The  tabletop  Is  never  the  master  in  a  projection. 

[2D  Building  projections  have  no  requirement  for  filtering  of  the  slave. 

State  Component  Definition: 

PROJSET 5 . 2 _ 

PROJSET4 . 2A 

(Vp  :  zan  (projdata)) 

[1]|  (dn  (masterspot  (p))  *  tabletop  a 

|[2  J  (dn  (slavespot  ( p ) )  #  tabletop  => 

panesize  -  (0,0) ) ) 


•TV 


DISPLAY5.3 


Basis: 

Prior:  DISPLAY4.3A 

Comments: 

We  can  now  require  that  the  user  select  only  a  portion  of  the  tabletop 
document  to  view. 

Requirements  /  Design  Decisions: 

HID  The  screen  displays  (part  of)  the  screen  document  (tabletop)  only. 
State  Component  Definition: 

D I SPLAY 4 _ 

DISPLAY4.3A 


|[1D  dn  (screenstart)  *  tabletop 


FILER5 


State  Definition: 

FILER5  a  FILER4 

(FILING  CABINET4.1A  FILING  CABINET5 . 1; 

PROJSET4.2A  &-P  PR0JSET5 . 2 ; 

DISPLAY 4 . 3 A  H>  DISPLAY 5 . 3 ) 

The  refined  FILER  state  space  Is  a  simple  restriction  of  the  previous 
state  space  definition. 

Of  course,  tabletop  is  a  derived  component  since  in  FILER1  we 
defined  what  the  appearance  of  every  coordinate  potentially  visible  to  the  user 
would  be.  Consequently. 

(VS  :  FILER5) 

docdatal  (S)  (tabletop)  -  fileview' 

(FILE-APPEARANCEF|LER5  [F ILER5/S]  ; 

PRO  JECTED-APPEARANCEf|LER5  ; 

appearancef|LER5) 


FILEB6 


Basis: 

Prior:  FILER5 

Forward:  FILING  CABINET6.1  /  PROJSET6.2  /  DISPLAY6.3 

Comments: 

This  specification  level  defines  a  number  of  size  and  extent  limitations. 
Many  of  these  limitations  will  be  only  abstractly  defined  so  that  actual  values 
can  be  given  to  them  after  additional  functional  decisions  and  non-functional 
requirements  have  been  defined. 


FILING  CABINET6.1 


Basis: 

Prior:  FILING  CABINET5.1 

Comments: 

The  limitations  to  be  placed  on  the  filing  cabinet  includes  a  maximum 
allowable  number  of  documents  in  the  filing  cabinet.  Additionally,  the  filing 
cabinet  can  be  simplified  by  restricting  the  background  colors  available. 

Requirements  /.Design  Decisions: 

111  The  background  paper  color  lor  all  documents  and  the  filing  cabinet 
background  color  will  be  the  same. 

121  The  tabletop  must  have  a  maximum  size. 

j[31  All  non-viewing  documents  must  have  a  maximum  size. 

141  The  filing  cabinet  has  a  maximum  number  of  documents  that  it  can 
hold. 

Auxiliary  Definitions: 

We  define  abstract  limits  for  the  filing  cabinet  here. 

a.  backcolor  e  speck 

b.  tablelength  €  JV 
tablewidth  c  JV 

c.  maxdoclength  e  JV 
maxdocwidth  e  JV 


d.  maxdocno  e  JV 


State  Component  Definition: 


PILING  CABINET6 . 1 _ 

FILING  CABINET5.1 


fflj  (Vp  :  ran  (colors))  (p  -  backcolor) 

Il]l  fllecolor  -  backcolor 

([ 2 B  rows  (docdata  (tabletop))  -  tablelength 
cols  (docdata  (tabletop))  -  tablewidth 

I3J  (Vd  :  dom  (docdata)  -  (tabletop)) 

(rows  (docdata  (x))  <  maxdoclength  A 
cols  (docdata  (x))  <  maxdocwidth) 

|[4]j  card  (dom  (docdata))  <  maxdocno 


PROJSET6.2 


Basis: 

Prior:  PROJSET5.2 

Comments: 

The  viewing  projections  have  been  restricted  here  to  filters  of  reverse 
video  (dark  on  light)  only.  This  decision  Is  based  on  the  normal  capability 
of  the  textual  display  screen  likely  to  be  used  with  this  system.  Also.  The 
maximum  number  of  projections  allowed  in  the  system  has  been  limited. 

Requirements  /  Design '  Decisions: 

tlH  The  only  filter  available  will  be  reverse  video. 

t2J  The  total  number  of  projections  allowed  is  limited. 

Auxiliary  Definitions: 

a.  revvideo  e  filter 

b.  maxproj  e  JV 
State  Component  Definition: 

PROJSET6 . 2 _ 

PROJSET5 . 2 


[I]  ( Vp  :  ran  (projdata)) 

(revvideo  -  retv-filter  (f  (p))) 

I2J  length  (projdata)  <  maxproj 


DISPLAY6.3 


Basis: 

Prior:  DISPLAY5.3 

Comments: 

This  advancement  commits  the  design  to  a  constant  sized  screen. 
Since  almost  all  textual  screens  are  of  fixed  length  and  width,  this  is  not 
a  significant  restriction  of  capability. 

Requirements  /  Design  Decisions: 

I1H  The  screen  on  which  the  user  sees  the  tabletop  will  have  a  constant 
size. 

Auxiliary  Definitions: 

a.  screenlength  c  JV 
screenwidth  c  JV 

State  Component  Definition: 

DISPLAY 6 . 3 _ 

DISPLAYS. 3 


ttlj  screensize  -  (screenwidth,  screenlength) 


FILERS 


Comments  (con't): 

Here  we  will  require  that  projections  link  documents  which  exist  within 
the  filing  cabinet.  This  will  impose  a  policy  of  projection  deletion  when  a 
master  or  slave  document  Is  deleted.  We  also  require  that  the  area  displayed 
to  the  user  is  totally  in  the  limited  extent  of  the  tabletop. 

Requirements  /  Design  Decisions: 

1 1 J  The  slave  and  master  documents  of  all  projections  must  exist  in  the 
filing  cabinet. 

1 2 1  The  master  of  all  projections  must  be  entirely  on  the  paper  of  the 

master  document. 

5  3 1  The  slave  of  viewing  projections  will  stay  on  the  tabletop. 

|[4I  The  area  of  the  screen  must  be  entirely  on  the  tabletop. 

State  Definition: 

F ILER6 _ 

FILERS (FILING  CABINET5 . 1  P-P  FILING  CABINET6 . 1 ; 

PROJSET5 . 2  P-P  PROJSET6 . 2 ; 

DISPLAYS  .  3  P-p  DISPLAY6 . 3 ) 


ran  (projdata)) 

(dn  (masterspot  (p))  €  dom  (docdata)  a 
dn  (slavespot  (p))  e  dom  (docdata)  a 
strip  (areaC  (r~  sterspot  (p) ,  projsize))  c 
(cols  (docucta  (dn  (masterspot  (p)))), 
rows  (docdata  (dn  (masterspot  (p))))) 

ran  (projdata)  | 

dn  (slavespot  (p))  -  tabletop) 

(strip  (areaC  (slavespot  (p),  projsize))  c 
area  ((1,1),  ( tablewidth, tablelength) ) ) 

|[4])  aread  (coord  (screenstart) ) ,  screensize)  c 

area  ((1,1),  (tablewidth, tablelength) ) 


Il]|  (Vp  : 


12 1 


131  (Vp  : 


FILER? 


Basis: 

Prior:  FILER6A 

Forward:  FILING  CABINET7.1  /  PROJSET7.2 

Comments: 

With  this  specification  we  begin  to  include  the  lower  level  details  of 
the  desired  system  by  introducing  another  specialized  document  called 
homedoc.  This  permanent  document  contains  the  significant  Information  the 
user  wishes  to  supply  about  each  user  defined  document  In  the  filing  cabinet 
(ie.  the  namelines  of  the  documents.)  The  homedoc  will  also  hold 
information  about  the  length  of  the  documents.  The  restrictions  imposed  here 
are  all  required  to  define  the  necessary  home  document. 


FILING  CABINET7.1 


Basis: 

Prior:  FILING  CABINET6.1 

Comments: 

This  advancement  places  the  homedoc  permanently  In  the  filing 
cabinet  and  defines  its  size. 

Requirements  /  Design  Decisions: 

(1]  The  home  document  is  always  In  the  filing  cabinet. 

12]  The  width  of  the  home  document  Is  the  same  as  the  maximum  allowable 
document  width. 

|£ 3 H  The  length  of  the  home  document  Is  determined  by  the  number  of 
documents  in  the  filing  cabinet  excluding  the  tabletop  document. 

Auxiliary  Definitions: 

a.  homedoc  e  docname 

State  Component  Definition: 

FILING  CABINET?.] _ 

FILING  CABINET6.1 


1 1]|  homedoc  e  dom  (docdatal) 

]2]  cole  (  docdata  (homedoc))  -  maxdocwidth 
13]  rows  (  docdata  (homedoc))  -  2  * 

(card  (dom  (docdata))  -  1) 


Basis: 


PROJSET7.2 


Prior:  PROJSET6.2  /  FILING  CABINET7.1  (Auxiliary  Definitions) 


Comments: 

Now  that  we  have  the  document  namelines  gathered  together  on  the 
homedoc  we  do  not  want  the  appearance  of  the  homedoc  to  be  spoiled 
by  projections  to  it.  Therefore,  we  eliminate  the  possibility  of  the  homeline 
document  ever  being  the  slave  of  a  projection.  We  also  specify  that  every 
normal  window  on  the  tabletop  must  have  its  appropriate  nameline  at  the 
top  to  Identify  the  document  being  displayed.  In  order  to  protect  the  user 
from  misplacing  windows  by  making  them  too  small  to  see.  we  require  that 
pan  of  the  nameline  must  always  show,  even  If  the  window  it  tops  is  too 
small  to  be  visible. 

(Since  viewing  projection  slaves  appear  like  windows  onto  a  document, 
we  shall  use  that  term  whenever  discussing  tabletop  areas  which  contain  a 
document  projection.) 


Requirements  /  Design  Decisions: 

S 1 D  The  home  document  Is  never  the  slave  In  a  projection. 

|[2]j  For  each  viewing  projection  which  does  not  have  the  home  document 
as  its  master,  there  Is  immediately  following  it  In  the  projection  list  a  nameline 
projection  from  the  home  document  to  the  top  of  the  viewing  projection 
window. 

[31  Namelines  always  appear  in  reverse  video  at  the  top  of  a  window. 
(41  A  projection  must  always  be  at  least  one  column  wide  so  that  its 
nameline  will  never  disappear  from  the  screen. 


State  Component  Definition: 


PROJSET7 . 2 _ 

PROJSET6 . 2 


|[1]1  (Vp  :  ran  (projdata))  (dn  (slavespot  (p))  *  homedoc 
I4J  a  dn  (slavespot  (p))  -  tabletop  => 

projsize  (p)  >  (1,0)) 

| [2  &  3]]  (Vp  :  ran  (projdata)  I 

dn  (masterspot  (p))  *  homedoc) 
a  dn  (slavespot  (p))  -  tabletop) 

(q  -  p  +  1  a 

dn  (masterspot  (q))  -  homedoc  a 
dn  (slavespot  (q))  -  tabletop  a 
coord  (slavespot  (q))  - 

coord  (slavespot  (p))  -  (1,0)  a 
retv-filter  (f  (q))  -  revvideo  a 
projsize  (q)  -  (x  (projsize  (p)),  1)  a 
startpane  (q)  - 

coord  (slavespot  ( p) )  -  (1,0)  a 
panesize  (q)  -  (x  (projsize  (p)),  1)) 


Notice  that  the  masterspot  for  the  nameline  projection  has  not 
been  defined  here,  it  can  be  more  easily  specified  in  the  FILER7  definition 
which  follows. 


FILER7 


Comments  fcon'O: 

In  this  specification,  we  had  to  add  a  new  component  to  the  definition 
of  FILER.  This  new  component  defines  the  relationship  between  the  existent 
filing  cabinet  documents  and  the  lines  of  the  home  document  which  contain 
the  namelines.  This  simple  function  will  help  build  the  nameline 
projection  required  with  each  of  the  viewing  projections. 

Requirements  /  Design  Decisions: 

S 1 1  For  each  non-tabletop  document  a  unique  entry  of  nameline  and 
document  length  is  made  on  homedoc. 

|£23|  The  home  document  nameiine  is  the  first  entry  in  the  home  document. 
Auxiliary  Definitions: 
a.  marker  e  speck 

This  will  abstractly  define  the  speck  to  be  used  as  a  document  length 
indicator  on  the  homedoc.  Each  occurrence  of  the  marker  represents  10 
lines  in  the  document  except  for  the  last  occurrence  which  could  represent 
any  number  of  lines  up  to  (and  including)  ten. 


b. 

odds  a  {2n  +  1  |  n  :  JVt) 

The  odds  set  will  define  the  lines  of  the  homedoc  which  contain 
namelines.  The  remaining  (even)  lines  of  the  homedoc  contain  the 
document  length  information  appropriate  to  the  document  described  by  the 
previous  nameiine. 


State  Component  Definition: 


P I LER7 _ 

FILERS 

(FILING  CABINET6.1  FILING  CAB INET7 . 1 
PROJSET6.2  ^  PROJSET7.2) 
point  :  docname  >— >  odds 

1 1J  dom  (point)  -  dom  (docdata)  -  {tabletop} 
a  ran  (point)  - 

{a  :  odds  |  a  <  2* (card(docdata)-l) } 

fflj  (Vd  :  dom  (point)) 

(3x  :  SEQ  [  {marker ,backcolor }  ]  I 
card  (x  J  {marker})  - 

(rows  (docdata  (d))  +  9)  DIV  10  a 
x  -  homedoc  (point  (d)  +1)) 

[2]|  point  (homedoc)  -  1 

(Vp  :  ran  (projdata)  I 

dn  (masterspot  (p))  *  homedoc  a 
dn  (slavespot  ( p ) )  -  tabletop) 

(q  -  p  +  1  a 

coord  (masterspot  (q))  - 

(point  (dn  (masterspot  (p))),  1) ) 


FILER7A 


Basis: 


Prior:  FILER7 

Forward:  FILING  CABINET7.1A  /  PROJSET7.2A  /  DISPLAY7.3A 


Comments: 

This  refinement  will  simplify  the  state  space  by  removing  the  tabletop 
document  from  the  list  of  filing  cabinet  documents.  Since  it  is  a  highly 
specialized  document  and  is  in  general  not  subject  to  the  same  restrictions 
and  operations  as  the  other  documents,  its  disassoclation  from  the  rest  of 
the  documents  serves  to  eliminate  some  of  the  previously  required  state 
predicates  and  operation  preconditions. 

Similarly,  we  can  create  separate  projection  lists  for  the  viewing  and 
building  projections;  thereby,  facilitating  the  definition  of  required  operations 
on  the  different  projection  types.  At  the  same  time,  we  will  eliminate  from 
the  projection  list  the  explicit  (but  derived)  nameline  viewing  projections 
which  are  used  to  top  the  normal  viewing  projections. 


FIUNQ  CABINET7.1A 


Basis: 

Prior:  FILING  CABINET7.1 

Comments: 

We  can  now  easily  remove  the  tabletop  from  the  rest  of  the 
documents  In  the  filing  cabinet. 

State  Component  Definition: 


FILING  CABINET7.1A _ 

FILING  CABINET7 . 1 

tabletop  :  DOCUMENTCLASS 

docdatal  :  docname  -*»  DOCUMENTCLASS 


tabletop  i  dom  (docdatal) 

docdata  -  docdatal  •  (tabletop  |— >  tabletop) 


PROJSET7.2A 


Basis: 

Prior:  PROJSET7.2 

Comments: 

Here  we  have  created  different  schemata  for  the  two  different  types 
of  projections,  allowing  the  elimination  of  the  unneeded  derived  components 
of  the  projections.  The  separation  of  the  projections  into  two  lists  does  not 
alter  the  ordered  property  of  the  projection  list  (le.  relative  projection  strength) 
because  the  two  types  of  projections  never  have  slaves  on  the  same  document. 

Auxiliary  Definitions: 


a. 


PROJCLASSB _ 

slavespot 

masterspot 

projsize 


COORD 

COORD 

coordinate 


prolsize  >  (0,0) 


PROJCLASSV 

slavespot 

:  coordinate 

masterspot 

:  COORD 

projsize 

:  coordinate 

startpane 

:  coordinate 

panes ize 

:  coordinate 

projsize  > 

(1,0) 

panes ize  > 

(0,0) 

aread  (startpane, panesize)  c 

aread  (slavespot, projsize) 

Viewing  projections  have  a  predetermined  slave  document  (tabletop) 
and  filter  (revvideo)  so  these  derived  components  can  be  removed  from 
the  projection  definition.  Of  course,  the  stained  glass  area  must  still  remain 
on  the  window  and  the  window  must  always  have  some  width. 


maxvproj  e  JV 
maxbproj  e  JV 

We  can  replace  the  general  restriction  on  the  number  of  projections 
by  individual  maximums  on  the  two  different  projection  types. 


retv-vprojection  :  PROJCLASSV  — *  (coordinate  -+»  COORD) 
retv-vprojection  a  (XP) 

(Xc  |  c  € 

aread  ( slavespot (P) ,projsize(P) ) ) 
(dn( master spot (P) ) , 

(coord(masterspot(P) )+c-slavespot(P) ) ) 


This  function  recreates  a  viewing  projection  from  a  PROJCLASSV 


schema. 


jVV' 


retv-bprojection  :  PROJCLASSB  — *  projection 
retv-bprojection  «  (XP) 

(XC  |  dn(C)  -  dn(slavespot (P) )  a 
coord (C)  € 

aread (coord (slavespot(p) ) , 

projaize(p) ) ) 

(dn(masterspot (P) ) , 

(coord(masterspot(P) )+coord(C)- 
coord(slavespot(P) ) ) ) 

Now  we  can  retrieve  a  building  projection  from  its  new  schema 
representation. 


State  Component  Definition: 


PROJSET7 . 2A _ 

PROJSET7 . 2 

proj build  :  SEQ  [PROJCLASSB] 

pro j view  :  SEQ  [PROJCLASSV] 


length  (projbuild)  <  maxbproj 
length  (proj view)  <  maxvproj 

(Vi,j  :  dom(projdata)  | 

dn(elavespot (pro jdata( i) ) )  *  tabletop  a 
dn(slavespot (projdata( j ) ) )  #  tabletop  a 

i  <  j) 

(3p,q  :  dom(projbuild)  | 
p  <  q  A 

retv-projection(projdata( i) )  - 

retv-bprojection(projbuild(p) )  a 
retv-projection(projdata( j ) )  - 

retv-bprojection(projbuild(q) ) ) 

(Vi , j  :  dom(projdata)  j 

dn(slavespot (projdata( i) ) )  -  tabletop  a 
dn(slavespot(projdata( j) ) )  -  tabletop  a 
i  <  j) 

(3pfq  :  dom(projview)  | 
p  <  q  A 

retv-projection(projdata( i) ) (tabletop, c)  - 
retv-bprojection(projview(p) ) (c)  a 
retv-projection (pro jdata( j ) ) (tabletop, c)  - 
retv-bprojection(proj /iew(q) ) (c) ) 

length(projdata/(PROJCLASS[dn(masterspot/homedoc] ) ) 

length (proj build)  + 

length ( proj view/ ( PROJCLASSV[ dn (master spot/homedoc ) ) ) 


Since  a  projection  from  the  building  projection  list  cannot  possibly 
cause  a  slave  overlap  with  a  projection  defined  in  the  viewing  projection  list, 
the  relative  order  of  the  projections  between  the  two  lists  is  unimportant. 
That  Is,  any  recombination  of  the  two  lists  which  preserves  their  individual 
orderings  will  produce  a  list  equivqlent  to  the  original  projection  list. 

Operations: 

The  following  operations  adhere  to  the  previously  defined  policy  of 
using  composition  to  move  or  size  objects  where  possible.  With  projections 
defined  by  starting  points  and  sizes,  the  addition  of  an  offset  becomes  the 
functional  equivalent  of  composition.  Ail  but  the  final  operation  involves 
projections  of  the  viewing  type. 


a. 

movewindow  :  PROJCLASSV  x  coordinate  — »  PROJCLASSV 
movewindow  a  (XP,o) 

PROJCLASSV  [  slavespot/slavespot(P)  +  o; 

masterspot/masterspot (P) ; 
projsize/projsize(P) ; 
startpane/startpane(P)  +  o; 
panesize/panesize(P)  ] 

Moves  the  window  and  Its  associated  stained  glass  according  to  the 
given  offset... 


b. 

movesg  :  PROJCLASSV  x  coordinate  PROJCLASSV 
movesg  a  (xp,o  |  aread ( startpane (P) +o , panes ize(P) ) 

c  aread (s laves spot (P) , projsize(P) ) ) 
PROJCLASSV  [  slavespot/slavespot (P) ; 

masterspot/masterspot (P) ; 
projsize/projsize(P) ; 
startpane/startpane(P)  +  o; 
panes ize/panes ize ( P )  ] 

Moves  the  stained  glass  by  the  offset  amount....  The  stained  glass 


must  remain  within  the  window. 


sizewindow  :  PROJCLASSV  x  BNT  x  BNT  x  BNT  x  J NT 


-+>  PROJCLASSV 

sizewindow  a  (XP,u,d,l,r  | 

projsize(P)+(r,d)+(l,u)  >  ( 1,0 )) 
PROJCLASSV  [  slavespot/slavespot (P)  -  (l,u); 

masterspot/masterspot (P)  - 

(l,u); 

projsize/projsize(P)  + 

(r , d)  f  (l,u); 
startpane/startpane(P) ; 
panesize/panesize(P)  ] 

Adjusts  the  size  of  the  window  by  adjusting  the  location  of  each  of 
the  window  sides....  The  projection  namellne  must  still  be  visible  after  the 
size  change. 


d. 

sizesg  :  PROJCLASSV  x  BNT  x  BNT  x  BNT  x  BNT 

PROJCLASSV 

sizesg  a  (XP,u,d,l,r  |  aread(startpane(P)-(l,u) , 

panesize(P)+(r ,d)+(l,u) )  c 
aread(slavespot(P) , projsize(P) )  a 
panesize(P)+(r ,d)+(l,u)  >  (0,0)) 
PROJCLASSV  [  slavespot/slavespot (P) ? 

masterspot/masterspot (P) ; 
projsize/projsize(P) ; 
startpane/startpane(P)  -  (l,u); 
panesize/panesize(P)  + 

(r,d)  +  (l,u)  ] 

To  change  the  size  of  the  stained  glass  area....  The  stained  glass 
will  remain  on  the  window  and  not  have  a  negative  size. 
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PRO J CLASS V 


removesg  :  PRO J CLASS V  —* 
removesg  ®  (XP) 

PRO J CLASS V  [  slavespot/slavespot(P) ; 

master  spot/master  spot ( P ) 
projsize/projsize(P) ; 
startpane/startpane(P) ; 
panes ize/( 0,0)  ] 

This  will  remove  the  stained  glass. 


createsg  :  PROJCLASSV  x  coordinate  x  coordinate 


createsg  « 


PROJCLASSV 

(XP,startc,stopc  I  startpane(P)  -  (0,0) 
a  startc  <  8 tope) 

PROJCLASSV  [  slavespot/8lavespot(P) ; 

masterspot/masterspot(P) ; 
projsize/projsize(P) ; 
startpane/startc ; 
panes ize/stopc-startc+( 1,1)  ] 


To  create  a  stained  glass  area,  there  must  not  be  such  an  area 
associated  with  the  projection  already  and  the  diagonal  of  the  desired  stained 
glass  area  must  be  properly  defined. 


scrolldoc  :  PROJCLASSV  x  coordinate 


PROJCLASSV 


scrolldoc  « 


<XP,o) 

PROJCLASSV  [  slavespot/slavespot (P) ; 
master spot/ 

(dn(masterspot(P) ) , 
coord(masterspot (P)  )+o)  ,* 
projsize/projsize(P) ; 
startpane/startpane(P) ; 
panesize/panesize(P)  ] 


The  master  of  a  projection  can  be  moved  with  an  offset. 


swap-projection  :  SEQ  [  PROJCLASSV  ]  X  x  JV, 

-+*  SEQ  [  PROJCLASSV  ] 

swap-projection  a  (XP,m,n  |  m  e  dom(P)  a  n  e  dom(P)) 

P  •  {m  (-»  P(n)>  •  (n  N  P(m)} 

The  strengths  of  two  existing  projections  in  the  viewing  projection  list 
are  swapped  by  this  function. 

The  following  function  deals  with  building  projections. 


createproj 

createproj 


COORD  x  coordinate  x  COORD  -**  PROJCLASSB 
(Xcloc,size,ploc  |  size  >  (0,0)) 
PROJCLASSB  [  slavespot/ploc ; 

master spot/cloc ; 
projsize/size  ) 


This  function  creates  a  building  projection  from  its  components. 


DISPLAY7.3A 


Basis: 

Prior:  DISPLAY7.3 

Comments: 

For  the  sake  of  simplicity,  we  rename  the  only  non-derived  portion 
of  the  DISPLAY  state  component. 

State  Component  Definition: 

DISPLAY7 . 3 A _ 1 _ 

DISPLAY7 . 3 

sstart  :  coordinate 


sstart  -  coord  (ecreenstart) 


FILER7A 


State  Definition: 

F ILER7A _ 

FILER7  (FILING  CABINET7 .1  P-fr  FILING  CABINET7.1A 
PROJSET7 . 2  P-P  PROJSET7.2A; 
DISPLAY 6 . 3  K>  DISPLAY7.3A) 


UMACHINE 


Basis: 

Prior:  FILER7A  /  EDDOC1A 

Comments: 

This  specification  recombines  the  decomposed  system  parts  —  the 
filer  and  the  editor.  Also  at  this  level,  many  of  the  user  required  commands 
can  be  initially  formulated.  In  order  to  facilitate  the  development  of  these 
commands,  a  number  of  new  components  have  been  added  to  the  state  space. 
Many  of  these  new  components  are  derived  from  the  current  state  parts  but 
provide  information  upon  which  decisions  will  be  made  within  the  commands. 

Finally,  this  specification  defines  a  subset  of  the  tabletop  document 
in  order  to  save  machine  resources.  Typically,  this  partial  tabletop  Is  defined 
by  a  starting  point  (called  the  screen  document  offset,  ecreendoff)  and 
a  size  parameter.  This  partial  tabletop  represents  the  first  decision  made 
about  how  the  screen  appearance  may  be  created  and  stored  in  our  system. 
It  Is  hopelessly  unrealistic  to  expect  that  the  tabletop  appearance  would  be 
recomputed  in  toto  after  each  state  changing  operation.  However,  it  may 
be  economical  to  compute  the  appearance  of  an  area  larger  than  just  the 
area  seen  by  the  user.  The  tabletop  section  Elected  for  appearance 
computation  is  called  the  screendoc.  The  following  figure  shows  the 
relationship  among  the  various  tabletop  document  components. 


(u) 


The  screen  document  must  remain  on  the  tabletop  document,  the  screen 
must  remain  on  the  screendoc  and  the  cursor  must  remain  on  the 
screen. 

Requirements  /  Design  Decisions: 

( l  ]  A  partial  tabletop  appearance  Is  all  that  could  be  economically 
computed  when  the  user's  display  changes  as  a  result  of  operations  on  the 
state  space.  Defining  this  partial  tabletop  larger  than  the  screen  area  may 
save  resources  so  we  leave  the  option  open. 

12]  Decisions  about  required  user  commands  noted  In  the  provisional  User's 
Manual  are  reflected  here. 

13]  No  editing  operations  (except  speck  replacement)  will  be  allowed  on 
document  lines  which  are  partially  determined  by  building  projections.  This 
eliminates  some  potentially  undesirable  effects  caused  by  the  Interaction  of 
projected  and  non-projected  information  (eg.  words  disappearing  under  a 
projection  during  an  Insert.) 

Auxiliary  Definitions: 

a . 

blankline  a  SEQ  [  {backcolor}  ] 
length  (blankline)  «  maxdocwidth 
blankmsg  a  SEQ  [  (backcolor)  ] 


length  (blankmsg)  -  screenwidth 

b. 

{newdoc, blankdoc)  c  docname 

A  new  document  which  has  not  yet  been  filed  permanently  and  a 
blank  document  will  be  required  in  the  filing  cabinet,  so  the  appropriate  names 
are  added  to  the  abstract  set  of  document  names. 

c. 

blankproj  a  PROJCLASSV[  slavespot/(l, 2) ; 

master spot/ (blankdoc, (1,1)); 
projsize/ 

(maxdocwidth, maxdoc length) ; 
startpane/( 1, 2) , 

__ _  _  panes  ize/(  0,0)  1 


This  projects  a  very  large  blank  document  to  the  upper  left  corner 
of  the  tabletop.  This  document  will  serve  as  the  backdrop  for  the  creation 
of  a  new  document. 

d. 

nullproj  a  PROJCLASSV[  a laves pot/ (1,2) ; 

masterspot/(newdoc, (1,1)); 
projsize/(l,0) ; 
atartpane/(l, 2) ; 
panesize/(0,0)  ] 

This  will  initialize  the  viewing  projection  for  the  creation  of  a  new 
document. 

e. 

blankdoc  a  DOCUMENTCLASS [  rows/maxdoclength ; 

cola/maxdocwidth  | 

(Vr  :  1. .maxdoc length) 

(Vc  ;  1. .maxdocwidth) 

(table  (r)(c)  -  backcolor)  ] 

This  Is  the  big  blank  document  which  will  hide  the  tabletop  from  the 
user  as  he  creates  a  new  document. 

f . 

homeproj  a  PROJCLASSVf  slavespot/(l, 1) ; 

master spot/ (homedoc, (1,1)); 
projsize/ 

(maxdocwidth, length (docdatal( homedoc) ) ) ; 
startpane/(l, 1) ; 
panes ize/ (maxdocwidth, 1)  ] 

To  display  the  home  document,  this  projection  will  be  added  to  the 
end  of  the  viewing  projection  list. 

9- 

emptydoc  a  DOCUMENTCLASS  [  table/<>  ) 


h. 


CAMERA _ _ _ _ 

loc  :  COORD 

size  :  coordinate 


size  >  (0,0) 


This  schema  represents  the  master  area  of  a  building  projection. 


i. 

none  £  docname 

edocname  -  docname  u  {none} 

sdwidth  c  JV 
sdlength  e  JV 

These  abstract  values  define  the  size  of  the  screen  document. 


k. 

odd  it  :  JVt  — »  JV1 
oddit  a  (xa) 

a  +  a  MOD  2-1 

Oddit  turns  even  and  odd  line  numbers  Into  odd  line  numbers. 


1. 

The  following  functions  are  used  to  insure  that  building  projections 
will  not  be  disturbed  by  the  editing  commands. 

check  :  docname  *  J IV  *  JV^  * 

SEQ  [  PROJCLASSB  ]  -+  P  (JV^ 
check  •  (Xd, width, line, B) 

{c  :  dom  (B)  |  (3i  ;  1. .width  | 

(i,line)  e 

aread  (coord(slavespot(B(c) ) ) , proJaize(b(c) ) ) 
_ Ad-  dn(slavespot (B(c  nm _ 


The  function  check  defines  the  set  of  ail  building  projections  which 
have  a  slave  area  that  Includes  some  portion  of  the  given  line. 

lineok  :  docname  *  J V  *  JV,  * 

SEQ  [  PROJCLASSB  ]  -♦  boolean 
lineok  a  (Xd, width, line, B) 

check  (d, width, line, B)  -  <b 

Lineok  Indicates  that  a  document  line  Is  free  of  building  projections 

to  it. 

linesok  :  docname  x  JV  *  * 

SEQ  [  PROJCLASSB  ]  -+  boolean 
linesok  ®  (Xd, width, line, B) 

check  (d,width, line,B)  n 
check  (d, width, line+l,B)  -  ♦ 

This  function  determines  if  a  line  and  its  successor  (If  any)  share 
a  building  projection  slave. 

areaok  :  docname  x  JV  x  JV1  x  JVt  x 

SEQ  [  PROJCLASSB  ]  -*  boolean 
areaok  a  (xd,width,etartl,stopl,B) 

cheek  «>•*««', n,B)  -  ® 

Finally,  an  entire  area  (sequence  of  lines)  Is  tested  by  this  function 
to  see  if  it  overlaps  the  slave  area  of  any  building  projection. 

m. 

innameline  :  SEQ  [  PROJCLASSV  ]  x  JV  x  coordinate  x 
coordinate  boolean 
innameline  a  (XP,vpno, cursor ,sstart) 

(vpno  0)  a 

(vpno  #  0)  cursor+88tart-(l, 1)  e 
aread(slavespot(P(vpno) )-(0, 1) , 

(x (pro jsize(P( vpno) ) ) , 1) ) 

It  will  be  important  at  times  to  know  If  the  cursor  is  In  the  nameline 
of  a  projection.  This  function  will  determine  that  Information. 


n. 


The  deletion  of  a  document  may  require  that  projections  referencing 
that  document  be  deleted. 

deletepv  :  SEQ  [  PROJCLASSV  ]  — »  docname 

-»>  SEQ  f  PROJCLASSV  ) 

deletepv  a  (XS) 

C  Ad) 

(ns  |  ran  (ns)  -  {t  :  ran  (S)  I 

dn  (mas  ter  spot  ( t) )  Ad) 
a  (Vi«j  :  dom  (ns))  (3p,q  :  dom  (S)  | 
i  >  j  =* 

p  >  q  a 

ns(i)  -  S(p)  a 
ns(j)  -  S(q) ) 

a  length  (ns)  - 

length  (S  i  (PROJCLASSV  | 

dn (master spot)  a  d  ))) 

With  this  function  we  can  delete  all  viewing  projections  which  have 
the  given  document  as  the  master  document. 

deletepb  :  SEQ  [  PROJCLASSB  ]  — »  docname 

—>  SEQ  [  PROJCLASSB  ] 

deletepb  a  (XS) 

(Id) 

(ns  |  ran  (ns)  -  (t  :  ran  (S)  | 

dn (master spot (t) )  Ad  a 
dn(8lavespot(t) )  Ad) 
a  (Vi,j  :  dom  (ns))  (3p,q  :  dom  (S)  | 

i  >  3  =* 

p  >  q  a 

ns(i)  -  S(p)  a 
ns(j)  -  S(q) ) 

a  length  is)  - 

lengt*  (S  J  (PROJCLASSB  | 

dn (master spot)  a  d  a 
dn(slavespot)  a  d))) 


We  have  created  a  function  which  will  delete  building  projections  which 
have  the  given  document  as  either  the  master  or  slave. 


o. 

vprojreduce  :  SEQ  [  PROJCLASSV  ]  x  docname  x  jv 
-*  SEQ  [  PROJCLASSV  ] 
vprojreduce  a  (XS,d,n) 

(ns  |  (Vx  :  1. . length(S) ) 

( (dn(master spot (S (x) ) )  #  d  v 
dn(masterspot(S(x) ) )  -  d  a 

y(coord(masterspot(S(x) ) )  + 
y(projsize(S(x)))-(l,l)  <  n  => 
ns(x)  -  S(x)) 

a  dn(masterspot (S(x) ) )  -  d  a 

y(coord(masterspot(S(x) ) )  + 
y(projsize(S(x)))-(l,l)  >  n  =» 
ns (x)  - 

PROJCLASSV  (  slavespot/slavespot (S (x) ) ; 

masterspot/masterspot (S (x) ) ; 
projsize/(x(projsize(S(x) ) ) , 
n+l-y(coord(masterspot(S(x) ) ) ) ) ; 
star tpane/star tpane ( S ( x ) ) ; 
panes ize/ 

(x( panes ize(S(x) ) ) , 
min( (y(panesize(S(x) ) ) , 
n+l-y(coord(masterspot(S(x) ) ) ) } )  ] 

In  order  to  Keep  the  master  of  a  projection  on  Its  master  document 
It  may  be  necessary  to  decrease  projection  sizes  if  documents  participating 
in  those  projections  are  decreased  in  size.  Of  course  the  pane  sizes  may 
have  to  be  reduced  too.  Those  projections  which  do  not  involve  the  reduced 
document  or  which  still  fit  on  the  document  even  after  the  document  is 
reduced  will  not  be  affected  by  this  function. 

The  auxiliary  definition  for  bprojreduce  Is  similar  to  the  above 
except  that  it  tests  and  produces  a  PROJCLASSB. 


P- 

tabletopdisplay  is  ABSTRACT 


This  represents  the  policy  for  moving  the  screen  and  for  automatic 
disclosure  required  to  insure  that  user  commands  do  not  force  the  cursor 
out  of  the  current  window  or  off  the  screen.  This  policy  may  include  the 
swapping  of  projection  strengths  to  uncover  parts  of  a  window  or  movement 
of  the  screen  on  the  tabletop  (screendoc). 

q* 

barupdate  :  *  docname  »  DOCUMENTCLASS  x  JW 

-+*  DOCUMENTCLASS 
barupdate  a  (Mine, d,H,  long  |  line  <  length(H)) 
bar length  <  long  => 

iter (enter ,( (long-bar length+9)  DIV  10)) 

(H(line) ) 

bar length  >  long  H 

where  barlength  a  10  ‘  (endline(line,H)-l) 

enter  :  SEQ  [  speck  ]  -*  SEQ  [  speck  ] 
enter  (S)  -  <marker>  *  head  (S) 

The  document  lengths  recorded  in  the  home  document  must  be 
updated  each  time  a  document's  length  is  changed.  This  function  updates 
these  length  bars  as  necessary. 

r . 

insert el  :  DOCUMENTCLASS  x  JW1  x  coordinate 

-»  DOCUMENTCLASS 

insertel  a  (Xd,l,c  |  y(c)  €  dom(d)  A 

x(c)  £  dom(d(y(c) ) ) ) 
paste  (d,y(c),{l  H*  (blankline  • 

(shift  (1-1);  ( iter (tail,x(c)-l)(d(y(c))))) 

P  (1. .cols(d) ) ) ) 

A  (y(c)  (—*  blankline  A 

iter (head, length (d(y(c) ))-x(c)+l)(d(y(c))) 

P  (1. .cols(d) ) ) 

This  function  divides  a  document  line  Into  two  parts  to  create  a  new 
line  In  the  document.  The  remainder  of  the  two  new  lines  is  filled  with  the 


deleteel  :  DOCUMENTCLASS  x  «  coordinate 

-►  DOCUMENTCLASS 

deleteel  a  (xd,l,c  |  y(c)  £  dom(d)  a 

x(c)  £  dom(d(y(c)))  A 
y(c)  <  length (d)) 
cut  (d  9  (y(c)  (— * 

iter (head, length (d(y (c) ))-x(c)+l)(d(y(c))) 

*  iter (tail, 1-1) (d(y(c)+l))  r  (1. .cols(d) ) ) , 
y(c) ,1) 

With  this  function  we  can  compress  two  document  lines  into  one  line 
of  the  proper  length. 

State  Definition: 

UMACH I NE _ 

F ILER7A 
EDDOC1A 

Proj 

cam 
cursor 
screendof f 
insertmode 
arrowcommand 
start 
stop 

msgline  * 

%%%  USEFUL  DERIVED  COMPONENTS 


whichdoc 

edocname 

show 

( newdoc , homedoc , tabletop) 

nodoc 

"i 

novproj 

JV 

nobproj 

JV 

vpno 

JV 

bpno 

JV 

svpno 

JV 

screendoc 

DOCUMENTCLASS 

length  (msgline)  <  scceenwidth  -  1 

%%%  fixes  blankdoc  permanently  in  the  filing  cabinet, 
blankdoc  e  dom  (docdatal) 

%%%  although  visible,  the  cursor  can't  be  in  a  blankdoc 
window. 

dn  (masterspot  (z))  <*  blankdoc 

%%%  the  doc.  to  be  edited  is  the  current  document, 
whichdoc  none  => 

docdatal  (whichdoc)  -  doc 

%%%  the  blankdoc  cannot  be  cluttered  by  projections. 

(Vb  :  ran  (projbuild)) 

(dn  (slavespot  (b))  #  blankdoc) 

size  (cam)  >  (0,0) 

%%%  the  cursor  stays  on  the  screen. 

cursor  £  area  ((1,1),  (screenwidth, screenlength) ) 

%%%  the  screendoc  stays  on  the  tabletop 
screendoff  €  area  ((1,1), 

(tablewidth-sdwidth+1, tablelength-sdlength+1) ) 

%%%  the  screen  stays  on  the  screendoc. 
sstart  e  aread ( screendoff , 

(sdwidth-screenwidth+1, sdlength-screenlength+1) ) 

nodoc  »  card  (docdatal) 
novproj  -  length  (projview) 
nobproj  -  length  (projbuild) 


%%%  the  projection  number  of  the  window  in  which  the 
cursor  is  —  including  the  nameline  of  the  window, 
vpno  *  0  <=> 

NOT  (3n  :  vpno+1. .novproj  |  (cursor+sstart-(l, 1) )  c 
aread(slavespot(zz)-(0, 1) ,projsize(zz)+(0, 1) ) ) 

A  (cursor+sstart-(l, 1) )  c 

aread(slavespot(z)-(0, 1) , projsize(z)+(0, 1) ) 

%%%  the  building  projection  which  is  the  last  in  the 
projection  network  for  the  cursor  location, 
bpno  #  0  «■ 

vpno  #  0 

a  a  -  {n  :  1. .nobproj  |  retv-vprojection(z) 

(cursor+sstart-(l, 1) ) 

€  dom(retv-bprojection(projbuild(n) ) ) } 

a  a  #  0 

a  bpno  *  max (a) 

t%f  the  second  strongest  viewing  projection  at  the  current 
cursor  location, 
svpno  #  0  <=> 

vpno  *  0 

a  NOT ( 3n  :  svpno+l. . vpno-1  |  (cursor+sstart-(l, 1) )  e 
aread(slavespot(zz)-(0, 1) , projsize(zz)+(0, 1) ) ) 
a  (cursor+sstart-(l, 1) )  e 

aread(slavespot(projview(svpno) )-(0, 1) , 

proj size (pro jview(svpno) )+(0, 1) ) 


%%%  this  picks  the  current  document  for  the  cursor 
location  if  that  spot  is  not  in  the  slave  of  a  building 
proj,  or  in  a  nameline, 
whichdoc  *  none  <=> 
vpno  #  0  a 

NOT  innameline(projviewrvpno, cursor , sstart)  a 
areaok( whichdoc , cols (docdatal (whichdoc) ) , 
y(coord(masterspot(z) ) ) , 

y( coord (mas ter spot (z) ) )+y(projsize(z) )-l)  a 
retv-vprojection(z) 

( cursor +sstart-( 1, 1) ) 

■  (whichdoc, posit ion) 


%  %  t  a  quick  shorthand  of  what  document  the  user  is  iseeing 
show  -  homedoc  «=» 


projview(novproj )  -  homeproj  a  whichdoc  «  homedoc 
show  -  newdoc 

newdoc  e  dom(docdatal) 
show  -  tabletop  «=» 

whichdoc  /  {homedoc, newdoc} 

rows  (screendoc)  -  sdlength 
cols  (screendoc)  -  sdwidth 

where 

z  «  projview  (vpno) 
zz  a  projview  (n) 


Operations: 

The  following  operations  will  use  this  delta  operation  In  the  initial 
definition  of  user  commands. 

AUMACH I NE - 

UMACHINE 

UMACHINE' 

Status '  :  STATUS 


status '  -  SUCCESS 


”**  NOTICE:  From  this  specification  forward  we  will  institute  a 
shorthand  convention  of  not  explicitly  showing  state  components  which  are 
not  changed  In  an  operation.  This  convention  can  safely  be  applied  because 
there  will  not.  at  this  or  following  levels  of  specfication,  be  any  cases  where 
the  result  of  an  operation  is  unknown  for  some  of  the  state  components  (which 
was  the  previous  meaning  given  to  leaving  state  components  unspecified.) 
This  new  convention  will  greatly  simplify  the  presentation  of  the  operations 
and  highlight  their  effect  on  the  state. 


These  user  commands  correspond  with  the  appropriately  named  user 
commands  described  in  the  provisional  user's  manual.  Therefore,  little  or 
no  additional  explication  about  WHAT  they  do  is  given  here.  An  explanation 
of  the  preconditions  or  how  they  insure  a  transition  to  a  legal  state  Is  afforded 
where  required.  This  explanation  will  also  present  a  shorthand  indication  of 
error  conditions  required  to  make  them  total  functions.  For  example,  in  the 
operation  DCREATE  (operation  c.)  is  the  precondition: 

%%l  there  must  be  room  for  the  new  document . (ERROR13 ) 
nodoc  <  maxdocno 

which  indicates  an  error  condition  of  the  form: 

NODOCROOM  ? _ 


SUMACH I NE 


status 1 


STATUS 


nodoc  -  maxdocno 


status*  -  ERROR13 


The  error  message  associated  with  ERROR13  is  listed  at  the  end  of  the 
specification.  Of  course,  the  total  operation  would  be  written  in  the  form: 

DCREATE  a  DCREATE  V  NODOCROOM?  V  . . . 

A  few  of  the  preconditions  do  not  have  an  error  status  associated  with  them. 
This  signifies  that  the  precondition  will  always  be  trivially  met  In  the  system 
and  therefore,  cannot  cause  the  operation  to  fail.  This  Is  usually  the  result 
of  preconditions  being  specified  as  conditions  for  the  operation  invocation 
(ie.  promoting  the  precondition  to  a  higher  level  in  the  system,  hierarchy) 
or  from  a  system  structure  which  precludes  the  possibility  of  the  precondition 
not  being  met. 


AUMACHINE 


projview*  -  projview  *  homeproj 
sstart'  -  (1,1) 
cursor'  -  (1,1) 

8creendoff'  -  (1,1) 
insertmode '  -  false 
arrowcommand'  -  false 

msgline'  -  'HOME--' , nodoc, 'DOCUMENTS  IN  THE  FILING 
CABINET' 

show '  -  homedoc 


CLEAN _ 

AUMACHINE 


projview'  -  <> 
insertmode'  -  false 
arrowcommand'  -  false 


msgline'  -  blankmsg 


DCREATI 


AUMACHINE 


%%%  there  roust  be  room  for  the  new  document. (ERROR 13) 
nodoc  <  maxdocno 

%%%  there  roust  be  room  for  the  new  projections. (ERR0R8) 
novproj  +  2  <  maxvproj 


docdatal'  -  docdatal 

0  {newdoc  |—»  emptydoc) 

0  {homedoc  f— * 

docdatal(horoedoc)  * 

<blankline, blankline) ) 

%%%  show  the  user  a  clean  new  sheet  of  paper  and  hide 
details  of  the  current  tabletop. 

projview'  •  projview  *  <blankproj ,nullproj ) 

point'  -  point  u  {newdoc  |~*  2  *  nodoc  +  1} 

sstart'  -  (1,1) 

cursor'  -  (1,1) 

screendoff'  -  (1,1) 

insertmode '  -  false 

arrowcomroand'  -  false 

rosgline'  •  blankrosg 

show'  -  newdoc 


AUMACHINE 

docdatal'  -  ( docdatal\{ newdoc ) )  u 

{newnaroe  |— *  docdatal  (newdoc)) 
projview'  -  delete  (projview, novproj-1) 
point'  -  ( point\{ newdoc } )  u 

{newnaroe  |— *  point  (newdoc)} 


insertmode '  -  false 
arrowcommand'  -  false 
msgline'  -  blankmsg 
show'  -  tabletop 

t%%  select  a  legal  but  unused  name. 

where  newname  e  r(docname  -  dom  (docdatal)) 


e. 

DTHROW _ 

SUMACH I NE 

d  docname 

%%%  certain  documents  must  remain  permanently  in  the 
filing  cabinet. 

d  t  (homedoc,  blankdoc} 

docdatal'  -  docdatal\{d}  • 

{homedoc  |—* 

delete(delete(docdatal(d) rpoint(d) ) 
point (d) ) } 

%%%  the  corresponding  projections  must  also  be  deleted, 
projbuild'  -  deletepb  (projbuild)  (d) 
projview'  -  deletepv  (projview)  (d) 
point'  ■  point\{d} 
insertmode'  -  false 
arrowcommand'  -  false 
msgline'  -  blankmsg 


AUMACHINE 


%%%  the  cursor  must  point  to  a  window  (ERR0R1)  but  not  a 
window  on  the  homedoc  or  the  blankdoc. 
vpno  #  0 

NOT  innameline (projview, vpno, cursor , sstart) 
dn  (master spot  (2))  i  (homedoc, blankdoc} 

proj '  -  (dn (master spot (z) ) ,retv-vprojection(z) 

(cursor+sstart-(l, 1) ) 
insertmode'  -  false 
arrowcommana'  -  false 
msgline'  -  blankmsg 


where  z  a  projview  (vpno) 


AUMACHINE 


%%%  the  cursor  must  be  in  a  window. (ERR0R1) 
vpno  #  0 

loc  (cam')  -  (dn (master spot (a) ) ,retv-vprojection(a) 

(startpane) ) 

size  (cam’)  -  panesize  (a) 
insertmode'  -  false 
arrowcommand'  -  false 
msgline'  -  blankmsg 

where  a  •  projview  (vpno) 


V  *,v. 


3  ' 


PROJCREATE _ , _ 

AUMACHINE 

%%%  there  must  be  room  for  a  new  building, 
projection. (ERR0R8) 

nobproj  <  maxbproj 

%%%  both  the  camera  area  (ERR0R14)  and  the  projector  area 
(ERR0R15)  must  still  exist. 

ar ead ( coord ( pro j ) , size(cam) )  c 

area( (1, 1) , (cols (a) , rows (a) ) ) 

aread ( coord (loc( cam) ) , size(cam) )  c 

area( (1, 1) , (cols(b) , rows(b) ) ) 

projbuild'  -  projbuild  u 

{ nobproj +1  I—* 

cr eatepro j ( loc ( cam) , s ize ( cam) , pro j ) } 
insertmode '  -  false 
arrowcommand '  -  false 
msgline'  -  blankmsg 


where 


a  ®  docdatal  (dn  (proj)) 
b  a  docdatal  (dn  (loc  (cam))) 


PROJREMOVE _ 

AUMACHINE 

!%t  this  selected  spot  points  to  the  slave  of  a  building 
projection. (ERR0R16) 
bpno  *  0 


'W 


proj build'  -  delete(projbuild,bpno) 
insertmode '  -  false 


IREMOVESG. 


AUMACHINE 


*  .%  must  be  in  a  window. (ERR0R1) 
vpno  #  0 

projview'  -  projview  9 

{vpno  H*  removesg(projview(vpno) } ) 
insertmode '  -  false 
arrowcommand*  -  false 
msgline'  -  blankmsg 


m. 

CREATESG. _ 

AUMACHINE 


%%%  must  be  in  a  window. (ERR0R1) 
vpno  *  0 

t 

%%%  the  designated  pane  area  must  be  within  the 
w indow ( ERR0R4 )  if  the  entire  window  is  not  stained  glas 
area(sstart,cursor+sstart-(l,l) )  c 

aread(slavespot (a) ,projsize(a) )  v 
innameline (projview, vpno, cursor , sstart) 

III  the  window  currently  does  not  have  a  pane. (ERR0R7) 
panesize  (a)  -  (0,0) 

NOT  innameline (projview, vpno, cursor , sstart)  s=> 
projview'  -  projview  • 

{vpno  I—* 

createsg  (a,  sstart,  cursor ■*-sstart-(  1, 1) ) } 


innameline ( pr o j  v iew , vpno , cursor , s at at t ) 
projview'  -  projview  • 

{ vpno  |— ► 
createsg 

(a, slaves (a) , slaves(a)+projsize(a)-(l, 1) ) } 

insertmode '  -  false 
arrowcommand'  -  false 
msgline'  -  blankmsg 

where  a  «  projview  (vpno) 


MOVEWINDOWL 


AUMACHINE 

offset 


coordinate 


%f%  must  be  in  a  window. (ERR0R1) 
vpno  #  0 

%%%  after  a  move  the  window  must  still  be  on  the  tabletop 
with  room  for  the  name line. (ERROR 5) 

aread(Blave8pot(a)+of f set ,projsize(a) )  c 

aread( (1,2), (tablewidth, tablelength) ) 

%%%  the  policy  on  disclosure  affects  what  the  user  sees  as 
a  result  of  this  operation. 

tabletopdisplay( cursor , sstart , of f set , screendof f , b, vpno) 

insertmode '  -  false 

arrowcommand'  -  true 

msgline'  -  'MOVE  WINDOW--USE  ARROWS' 


where  a  «  projview  (vpno) 
b  a  projview  • 

{vpno  I—*  movewindow  (a) (offset)) 


MOVESG _ 

AUMACHINE 
offset 

%%%  must  be  in  a  window. (ERRORl) 
vpno  i*  0 

%%%  the  window  has  a  stained  glass . (ERR0R2) 
panesize  (a)  >  (1,1) 

%%%  the  location  of  the  stained  glass  after  the  move  must 
be  in  the  window. (ERR0R4) 

ar ead ( star tpane ( a) +off set, panesize (a) )  c 
aread(slavespot(a) , projsize(a) ) 

projview'  -  projview  9 

{vpno  f-»  movesg  (a) (offset)) 
insertmode '  -  false 
arrowcommand '  -  true 

msgline*  -  'MOVE  STAINED  GLASS — USE  ARROWS' 


where  a  a  projview  (vpno) 


!%%  master  stays  on  document. (ERROR3) 

aread (coord (master spot (zz) ) , projsize(zz) )  c 

area( (1,1) , (cols(docdatal(dn(masterspot(zz) ) ) ) , 
rows(docdatal(dn(masterspot(zz) ) ) ) ) 

%%%  window  stays  on  the  tabletop  with  room  for  the 
nameline. (ERROR 5 ) 

aread (slavespot(zz) , projsize(zz) )  c 

aread ( (1,2) , (tablewidth, tablelength) ) 

%%%  the  nameline  remains  visible . (ERR0R18) 
projsize  (zz)  >  (1,0) 

%%%  the  policy  on  disclosure  affects  what  the  user  sees  as 
a  result  of  this  operation  if  the  offset  is  not  (0,0). 

tabletopdisplay(sstart, cursor , (a,b) , screendof f , z, vpno) 

insertmode'  «  false 
arrowcommand'  -  true 

msgline '  -  'CHANGE  WINDOW  SIZE — USE  ARROWS' 

%%%  here  we  define  the  offset  to  be  used  to  move  the 
cursor  —  no  movement  is  done  unless  required  to  keep 
cursor  on  new  window  or  nameline, 
where  c  a  cursor+sstart- ( 1, 1)  - 

slavespot (projview( vpno) )  +  (0,1) 
d  a  slavespot (projview( vpno) )  + 

projsize(projview(vpno) )  -  (1,1)  - 
( cursor +sstart-(l, 1) ) 

left  +  x(c)  <  0  =*>  a  -  -(left  +  x(c)) 
right  +x(d)  <  0  =*  a  -  right  +  x(d) 

left  +  x(c)  >  0  a  right  +  x(d)  >  0  =>  a  -  0 

up  +  y(c)  <  0  =*  b  -  -(up  +  y(c)) 

down  +  y(d)  <  0  b  -  down  +  y(d) 

up  +  y(c)  >  0  a  down  +  y(d)  >  0  =>  b  -  0 


z  -  projview  •  {vpno  |— * 

sizewindow  (projview(vpno) ) (down, up, right, left) ) 
zz  -  z  (vpno) 


This  window  sizing  operation  can  be  used  for  both  expansion  and 
retraction. 


S I ZESG _ 

AUMACHINE 

up, 

down, 

left, 

right  :  tNT 


%%%  must  be  in  a  window. (ERROR1) 
vpno  0 

%%%  the  revised  stained  glass  must  stay  on  the 
window. (ERROR4) 

aread ( startpane ( z ) , panes ize(z) )  c 

aread(slavespot (z) ,projsize(z) ) 

%%%  the  window  has  a  stained  glass  pane. (ERR0R2) 
panesize  (projview  (vpno))  >  (1,1) 

%%%  the  resized  pane  must  still  be  visible. (ERR0R19) 
panesize(z)  >  (1,1) 

projview*  -  projview  0  (vpno  h-» 

sizesg  ( projview (vpno) ) (up, down, left, right) } 
insertmode '  -  false 
arrowcommand *  -  true 

msgline  *  -  'CHANGE  STAINED  GLASS  SIZE--USE  ARROWS' 


where  z  -  projview'  (vpno) 


OFFHOf 


AUMACHINE 

projview'  -  delete  (projview, novproj ) 
sstart'  -  (1/1) 
cursor’  -  (1/1) 
screendoff*  -  (1/1) 


insertmode 


false 


arrowcommand 1  -  false 
msgline*  -  blankmsg 
show'  -  tabletop 


If  the  user  is  viewing  the  home  document  and  wishes  to  return  to 
the  normal  tabletop  picture  he  will  push  the  HOME  key  and  activate  this 
operation. 


CHOOSI 


AUMACHINE 


%%%  the  user  must  be  viewing  the  homedoc  to  select  this 
operation. 

show  -  homedoc 

%%%  we  make  the  decision  to  preclude  the  user  selected 
windows  from  displaying  the  homedoc. 
a  #  homedoc 


projview'  - 


delete  (projview, novproj )  * 

<  PROJ CLASS V  (  slavespot/(l, 2) 

master  spot/ ( a,  (1,1)) 
projs ize/ 

(cols (a) , rows (a) ) 
startpane/ ( 1 , 2 ) 
panes ize/ (0,0)  ]  > 


sstart'  -  (1,1) 
cursor*  -  (1*1) 
screendoff*  -  (1,1) 
insertmode '  -  false 
arrowcommand'  -  false 
msgline*  -  blankmsg 
show'  -  tabletop 

where  a  a  point-1  (oddit  (y  (cursor+sstart-(l, 1) ) ) ) 


This  operation  will  create  a  full  document  sized  projection  from  the 
document  the  user  has  chosen. 


AUMACHINE 

offset 


coordinate 


%%%  must  be  in  a  window. (ERR0R1) 
vpno  #  0 

%%%  the  master  of  the  window  creating  projection  must 
still  be  on  the  master  document  after  this 
command . ( ERR0R3 ) 

aread(coord(masterspot (a) )+of f set,projsize(a) )  e 
area( (1,1) , (cols (b) , rows(b) ) ) 

projview'  -  projview  • 

(vpno  (— *  scrolldoc  (a, off set)) 
insertmode'  -  false 
arrowcommand'  -  true 

msgline*  -  'SCROLL  OR  ADJUST- -USE  ARROWS* 


where  a  *  projview  (vpno) 

b  ■  docdatal  (dn  (masterspot  (a))) 


AUMACHINE 


insertmode '  »  true 
arrowcommand '  -  false 
msgline'  -  'INSERTING* 


INSERT _ 

AUMACHINE 

s  :  speck 

%%%  must  be  in  a  window. (ERROR1) 
vpno  #  0 

%%%  must  be  on  a  line  free  of  building  projection  slaves 
or  else  in  the  nameline . (ERR0R6) 

(whichdoc  -  none)  =* 

innameline(projviewr vpno, cursor , sstart) 

(whichdoc  *  none)  => 

lineok( whichdoc, cols (docdatal(whichdoc) ) , 
y(position) ,projbuild) 

%%%  there  must  be  room  within  the  left  margin  set  by 
window  for  inserted  character . (ERR0R12) 
endline  (y(c) ,docdatal(d) )  < 

x(coord(masterspot (a) )  +  projsize(a)  -  (1,1)) 

%%%  if  the  cursor  is  not  at  margin  (right  edge  of  window) 
then  this  operation  may  require  disclosure. 
x(cursor  +  sstart  -  (1,1))  < 

x(coord(slavespot(a) )  +  projsize(a)  -(1,1))  => 
tabletopdisplay( sstart, cursor ,(1,0), 
screendof f , projview, vpno) 


docdatal'  -  docdatal  • 


{d  I— »  inserts  (docdatal(d) , c, s) 

P (1. . cols(docdata(d) ) ) } 

arrowcommand '  -  false 

where  a  a  projview  (vpno) 

b  a  dn  (masterspot  (a)) 

whichdoc  #  none  =*■  c  a  position  Ada  whichdoc 
whichdoc  -  none  =>  c  a  (x(retv-vprojection(a) 
(cursor+sstart-(l, 1) ) ) ,y(point(b) ) ) 
Ada  homedoc 


w. 


DELETE _ 

AUMACHINE 


%%%  must  be  in  a  window. (ERRORl) 
vpno  #  0 

%%%  must  be  on  a  line  free  of  building  projection  slaves 
or  else  in  the  nameline  (ERR0R6 )  (but  not  at  end  of 
nameline (ERROR20) ) . 

(whichdoc  -  none)  => 

innaume  line  (projview,  vpno,  cursor ,  sstart) 
a  x(c)  <  endline  (y(c) ,docdatal(d) ) 

%%%  combining  two  lines  cannot  disrupt  a  building 
projection. (ERR0R6 ) 

(whichdoc  a  none)  =* 

lineok(whichdoc,cols(docdatal(whichdoc) ) , 
y(position) ,projbuild) 

%%%  there  must  be  something  in  the  next  line . (ERROR20) 
a  x(c)  >  endline  (y(c) ,docdatal(d) )  =» 

(rows (docdatal (d)  >  y(c)  a 


%%%  the  resultant  line  must  fit  in  the  margins . (ERROR 12 ) 
x(c)+endline(y(c)+l,docdatal(d) )  - 
x( coord (master spot (a) ) )  < 
x( coord (master spot (a) )+projsize(a)-(lf 1) ) 

%%%  character  delete. 
x(c)  <  endline  (y(c) ,docdatal(d) )  =* 
docdatal'  -  docdatal  *  (d  [— * 

deletes (docdatal(d) , c)  *  <backcolor>} ) 

%%%  carriage  return  deletion  changes  document  size  —  may 
also  affect  projections  and  length  indicator. 
x(c)  >  endline  (y(c) , docdatal (d) )  =» 

(docdatal-'  -  docdatal  *  {d  |— ► 

deleteel(docdatal(d) , c) }  *  (homedoc 
I— »  barupdate (point (d )  +1 , d , 
docdatal (homedoc) , 
length (docdat al' (d) )) )  a 

proj build'  - 

bprojreduce(projbuild,d,rows(docdatal' (d) )  a 
projview'  - 

vprojreduce(projview,d, rows (docdatal' (d) ) ) 

insertmode'  -  false 
arrowcommand '  *  false 
msgline'  -  blankmsg 

where  a  a  projview  (vpno) 

b  »  dn  (masterspot  (a)) 

whichdoc  #  none  =*  c  a  position  Ada  whichdoc 
whichdoc  -  none  c  a  (x(retv-vprojection(a) 
(cursor+sstart-(l,0) ) ) , point (b) ) 

Ada  homedoc 


AUMACHINE 


%%!  must  be  in  a  window  (not  in  name line) . (ERRORl) 
vpno  #  0 

NOT  innameline ( pro jview/ vpno, cursor , sstart) 

%%%  the  window  has  a  stained  glass . (ERROR2) 
panesize  (z)  >  (1,1) 

%%%  the  stained  glass  selected  lines  are  not  touched  by 
building  projection  slave. (ERR0R6) 

areaok  (whichdoc, cols (docdatal(whichdoc) ) , a, 
a+y(panesize(z) )~l,projbuild) 

%%t  changes  document  size  —  may  affect  projections  and 
length  indicator. 

docdatal'  -  docdatal  9 

{whichdoc  (— > 

cut (docdatal(whichdoc) ,a-l, 
y(panesize(z) ) ) )  9 
{homedoc  |— > 

bar update (point (whichdoc) +1, 
whichdoc, docdatal (homedoc) , 
length (docdatal' (whichdoc) ) ) ) 
projbuild'  -  bprojreduce(projbuild, whichdoc, 

rows (docdatal' (whichdoc) ) ) 
projview'  -  vprojreduce(projview, whichdoc, 

rows (docdatal' (whichdoc) ) ) 

insertmode'  -  false 
arrowcommand '  -  false 
msgline'  -  blankmsg 


where  z  a  projview  (vpno) 

a  a  y(retv-vprojection  (z)  (startpane(z) ) ) 


AUMACHINE 

s  :  speck 


%%%  must  be  in  a  window. (ERRORl) 
vpno  #  0 

docdatal'  -  docdatal  *  {d  |— * 

alter  (docdatal(d) ,c,s) 

%%%  if  the  cursor  is  not  at  the  margin  (edge  of  the 
window)  then  disclosure  may  be  required. 
x(cursor+sstart-(l,  1) )  < 

x(coord(slavespot (a) )+projsize(a)-(l,  1)  => 
tabletopdisplay  (sstart, cursor ,(1,0), 
screendoff , projview, vpno) 
arrowcommand ’  -  false 
msgline'  -  blankmsg 

where  a  a  projview  (vpno) 

b  a  dn  (masterspot  (a)) 

whichdoc  a  none  =>  c  a  position  Ada  whichdoc 
whichdoc  -  none  c  a  (x(retv-vprojection(a) 
(cursor+sstart-( 1, 0) ) ) , point (b) ) 
Ada  homedoc 


This  operation  replaces  one  speck  with  another. 


z . 

NEWLINE 


AUMACHINE 


%%%  in  window  but  not  in  nameline  (ERR0R1)  and  line  free 
of  building  projection  slaves. (ERR0R6) 

NOT  innameline (proj view, vpno, sursor , sstart) 
vpno  *  0 

lineok  (whichdoc, position, docdatal(whichdoc) ) 

%%%  there  must  be  room  in  the  document . (ERR0R11) 
rows (docdatal(whichdoc) )  <  maxdoclength 

%%%  the  new  line  must  fit  within  the  margins 
given. (ERR0R12 ) 

endline(y(position) , docdatal (whichdoc) )  - 
x  (position)  < 

x  (sizeproj (proj view(vpno) ) 

%%%  the  change  in  the  document  length  may  affect  the 
length  indicator. 

docdatal'  -  docdatal  9  {whichdoc  |— * 

insertel  (docdatal(whichdoc) , position) }  9 
(homedoc  |— »  barlength(point (whichdoc) +1, 
whichdoc, docdatal (homedoc) , 
length (docdatal' (whichdoc) ) ) ) 

arrowcommand '  -  false 

%%%  disclosure  may  affect  the  picture  seen  by  the  user, 
tabletopdisplay  (sstart , cursor , 

(x(slavespot(z) )  -  cursor-sstart+(l, 1) ) , 1) , 
screendof f , a, vpno) 

where  z  a  projview  (vpno) 

y(slavespot(z) )  >  y(cursor+sstart-(l, 1) )  => 
a  -  projview 

y(slavespot(z) )  -  y(cursor+sstart-(l, 1) )  => 

a  -  projset  9  {vpno  >  sizewindow( z ) ( 0 , 1, 0 , 0) } 

This  operation  creates  two  lines  from  one  when  given  a  carriage 


return. 


REVERSE 


Basis: 

Prior:  UMACHINE 

Comments: 

To  allow  certain  of  the  required  user  commands  to  be  reversible, 
we  must  save  the  previous  state  description.  The  easiest  manner  in  which 
to  accomplish  this  is  simply  to  have  two  versions  of  the  state,  the  current 
version  and  the  previous  version. 

State  Definition: 

REVERSE _ 

UMACHINE 

UMACHINE* 


The  components  of  the  old  version  of  the  state  are  denoted  by  the 
component  name  with  the  #  superscript  affixed. 

Operations: 


A RE VERSE _ 

REVERSE 
REVERSE ' 


status  1 


STATUS 


status ' 


SUCCESS 


UNDO  Is  not  reversible;  therefore,  we  don't  care  what  happens  to 
the  old  state  components  once  they  are  used  to  reverse  the  effects  of  a 
command. 

b. 

PASTE _ 

ARE VERSE 


%%%  there  must  be  something  to  paste 
panesize  (z)  >  (1,1) 

%%%  the  user  must  have  selected  a  receiving  location 
within  a  spot  where  no  building  projection  has  a  slave, 
vpno  #  0 

NOT  namel ine (proj view, vpno f cursor , sstart) 
linesok  (whichdoc, cols (docdatal(whichdoc) ) , 

y( posit ion) , proj build) 

%%%  the  resulting  document  must  not  be  too  long. 

rows (docdatal (whichdoc) )  +  y (panesize(z) )  < 

maxdoclength 


%%%  both  documents  must  be  the  same  width. 

cols  (docdatal  (whichdoc))  -  cols  (c) 


%%%  update  the  document  and  its  length  entry  in  homedoc. 
docdatal'  -  docdatal  9 

{whichdoc  |— »  paste(docdatal(whichdoc) , 
y(position) , pastedoc) }  9 
{homedoc  (— »  barupdate(point(whichdoc)+l, 
whichdoc, docdatal (homedoc) , 
length (docdatal' (whichdoc) ) ) ) 

%%%  return  the  user  to  the  place  from  which  the  material 
was  copied. 

sstart'  *  sstart* 
cursor'  -  cursor* 
screendoff  -  screendoff* 
insertmode'  -  false 
msgline'  -  blankmsg 

where  z  a  projview*  (vpno*) 

c  a  docdatal*  ( dn ( mas ter spot (z) ) ) 

%%%  The  document  to  be  pasted  in  is  created  from  the  donor 
area  by  determining  the  appearance  of  each  point  in  the 
area. 

%%%  This  means  that  shared  information  and  the  information 
basic  to  the  donor  document  is  pasted, 
pastedoc  :  ARRAY  [  speck  ] 
length  (pastedoc)  -  y  (  panesize  (z)) 

(Va  :  1. . length(pastedoc) ) 

(length  (pastedoc  (a))  -  cols(c)) 

(Vx  :  l..cols(c))  (Vy  :  1. . length(pastedoc) ) 

(pastedoc  (y)  (x)  - 

prjview'  ( (FILE-APPEARANCERLER7A; 

pro  jected-appearancef|LER7A  ) 

(c,  (x,  y(c(masterspot(z) ) )+y-l) ) ) ) 


The  paste  command  uses  the  previous  state  description  to  define 
where  the  material  to  be  pasted  is  located  and  where  to  return  the  user 


after  the  paste  command  terminates.  Notice  that  since  this  command  pastes 
in  the  information  as  it  appears  to  the  user  (le.  including  copies  of  shared 
information),  there  Is  the  possibility  of  attemping  to  paste  undefined  specks. 

c . 

CRE  ATEW I NDOW _ 

ARE VERSE 

%%%  The  following  represents  the  decision  to  disallow  a 
user  defined  window  from  showing  the  home  document, 
a  *  homedoc 

%%%  the  document  must  not  be  too  small  to  fill  the  entire 
window. (ERRORIO) 

docdata2  (a)  >  y (stop-start)  +  1 

projview'  -  delete  (projview, novproj )  * 

<  PROJCLASSV[slavespot/start ? 

masterspot/(a, (l,b) ) ; 
projsize/(stop-start+(l,l) ) ; 
startpane/start ; 
panesize/(0 , 0) ]  > 

sstart'  -  sstart* 
cursor'  -  cursor* 
screendoff'  -  screendoff* 
insertmode'  -  false 
arrowcommand '  -  false 
msgline'  -  blankmsg 
show'  -  tabletop 

where  a  a  point-1  (oddit  (y  (cursor+sstart-(l, 1) ) ) ) 

10  *  (x(position)-l)  +  y (stop-start)  +1 

>  docdata2(a)  => 
b  -  10  *  x(position) -1)  +  1 
10  *  (x(position)-l)  +  y (stop-start)  +1 

<  docdata2(a)  => 
b  ■  docdata2(a)  -  y (stop-start ) 


MACHINE  1 


Basis: 

Prior:  REVERSE 

Comments: 

At  this  level  of  specification  we  can  Introduce  the  system  hardware 
representation  into  our  machine  state.  The  selected  target  machine  Is  the 
LSI  11-03  with  printer  (or  print  file),  floppy  disk,  and  KGM  PT700  character 
display  screen.  This  hardware  will  accommodate  all  of  the  prior  assumptions 
we  have  made  about  the  underlying  machine  (eg.  reverse  video,  textual  display 
screen,  etc.)  Because  -of  the  availability  of  disk  storage,  we  will  specify  that 
copies  of  the  filing  cabinet  documents  are  on  secondary  storage.  That  will 
allow  the  option  of  removing  the  now  derived  documents  from  main  store. 
It  is  unlikely  that  the  machine  will  be  big  enough  to  permit  the  filing  cabinet 
to  be  completely  main  storage  resident. 

Requirements  /  Design  Decisions: 

HID  All  documents  are  filled  with  characters  only. 

I2J  The  hardware  selected  Is  the  LSI  11-03  with  disk,  printer,  and  textual 
display  terminal.  A  standard  keyboard  with  directional  keys  and  28  definable 
function  keys  provide  the  user  input. 

Auxiliary  Definitions: 

a.  fname  is  ABSTRACT 

Disk  filename  formats  are  left  unspecified. 

b.  record  is  ABSTRACT 

The  organization  of  data  on  the  disk  is  left  unspecified.  We  will  not 
attempt  to  define  what  constitutes  a  record  but  will  assume  that  whatever 
we  specify  to  go  on  the  disk  will  satisfy  the  criteria  for  the  set  of  records. 


character  a  {a, b, c , d , e , f , g , h, i , j , k, 1 , m, 
n,o,p,q,r,s,t,u,v,w,x,y,z, 
A,B,C,D,E,F,G,H, I , J  f K,L,M, 
N,0,P,Q,R,S,T,U,V,W,X,Y,Z, 

!  '»(»)f-»Mi '» 

t i t ' t ] t 

@»[»~»t,\rl»2,3,4,5,6,7,8/9,0) 
U  {sp} 


This  is  the  standard  visible  ASCii  character  set  which  will  be  used 
to  create  the  documents. 

d. 

speck  a  character  u 

revvideo  (J  character  0 

Specks  are  visible  on  the  screen  as  well  as  including  the  character 
set  used  to  create  documents.  Therefore,  the  specks  must  Include  all 
characters  In  reverse  video. 

e. 

docdisk  €  docname  -*  fname 

docdisk*  €  docname  — *  fname 

ran  (docdisk)  n  ran  (docdisk*)  -  ® 

These  two  functions  turn  document  names  into  their  corresponding 
disk  file  names.  The  decorated  function  will  be  used  to  give  unique  disk 
file  names  to  documents  of  the  previous  state. 

f . 

DISK - 

fname  -*+  SEQ  (  record  ] 


This  schema  allows  us  to  describe  the  system  disk  very  abstractly. 


State  Definition: 


MACH I NE  J _ 

121 

|%t  secondary  store 

disk  :  DISK 

!%%  printer 

printer  :  SEQ  [  line  :  SEQ  [  character  ]  ] 

%%%  main  storage 

Ill  REVERSE  (DOCUMENTCLASS[ speck] 

DOCUMENTCLASS [ character ] ) 
docdata2  :  docname  -+*  i V 


%%%  the  lengths  of  the  documents  will  be  a  useful  derived 
component  to  define. 

dom(docdatal)  -  dom(docdata2 ) 

(Vd  :  dom(docdatal) ) 

(docdata2(d)  -  rows (docdatal(d) ) 

%%%  both  the  old  and  the  current  documents  are  on  the  disk 
and  must  have  unique  disk  names. 

(Vd  :  dom  (docdatal*)) 

(disk  (docdlsk*(d) )  -  docdatal*  (d)) 

(Vd  :  dom  (docdatal)) 

(disk  (docdisk  ( d ) )  -  docdatal  (d)) 


Operations: 


PR I NT _ 

AMACHINE1 


printer'  -  printer  *  P 
insertmode '  -  false 
ar r ow command1  -  false 
msgline*  •  blankmsg 


where 

%%%  Print  the  whole  document  as  it  exists  in  the  filing 
cabinet. 

(show  -  homedoc)  P  -  docdatal(a) 
a  a  point-1  (oddit  (y  (cursor+sstart-(l, 1) ) ) ) 

%%%  Print  the  screen. 

(show  *  homedoc  A 

NOT  innameline(projview, vpno, cursor ,sstart) )  = 
(P  e  ARRAY  [  character  ]  a 
length (P)  -  screenlength  a 
(Va  :  1. . screenlength) 

(length(P(a) )  -  screenwidth)  a 
(Vx  :  1. . screenwidth) (Vy  :  1. .screenlength) 
(P(y)(x)  -  screendoc 
(y(sstart)+y-y(screendoc) ) 

(x(sstart)+x-x(screendoc) ) ) ) 


%%%  Print  the  entire  window. 

(show  #  homedoc  a 

innamel ine(proj view, vpno, cursor , sstart ) )  => 

(P  6  ARRAY  (  character  ]  A 
length(P)  -  y  (projsize  ( z ) )  a 
(Va  :  1. . length(P) ) 

(length(P(a) )  -  x  (projsize  (z)))  a 
(Vx  :  1. .x(projsize(z) ) ) (Vy  :  1. . length(P) ) 
(P(y) (x)  -  pr jview' 

(  (FILE-APPEARANCEF|LER7A; 

pro  jected-appearancef|LER7A  ) 
(dn (master spot ( z ) , 
c (master spot ( z ) )-(l,l) ) ) ) ) 

where  z  e  projview  (vpno) 


MACHINE1A 


Basis: 

Prior:  MACHINE! 

Comments: 

Only  some  of  the  user  commands  change  documents  In  the  filing 
cabinet  and  even  these  commands  change  only  a  few  documents.  It  is 
unnecessary,  therefore,  to  save  the  entire  set  of  documents  that  were  in  the 
old  filing  cabinet  just  In  case  the  user  changes  his  mind  with  a  reverse 
command.  This  refinement  utilizes  that  fact  to  redefine  the  disk  in  a  more 
economic  fashion  by  not  keeping  duplicates  of  unchanged  documents. 

State  Definition: 


MACHINE1A _ 

MACHINE1 

docnamel 

docname2 

docname3 

diakl 


edocname 

edocname 

edocname 

DISK 


diakl  -  disk  P  a 

docnamel  -  none  =*■  docname2  -  none 
docname2  -  none  =>  docname3  -  none 

where  a  a  docdisk  Q  dom(point)  D  u 

docdisk*  Q  {docnamel, docname2,docname3}  -  {none}  D 


The  most  a  user  command  could  change  is  three  documents: 
therefore,  we  add  three  document  name  components  to  the  state  to  hold  the 
names  of  the  affected  documents.  The  new  disk  component  will  hold  only 
the  current  documents  and  up  to  three  old  documents  required  in  case  of 
a  command  reversal. 


A MACH I NE 1A 
UNDO 


docnamel'  -  none 
docname2 '  -  none 
docname3 '  -  none 


The  reverse  removes  the  backup  documents  after  making  them  the 
current  documents. 


b. 


DCREATE. 


AMACHINE1A 
DCREATE 


REVERSE 


docnamel*  -  homedoc 
docname2'  -  none 
docname3 '  -  none 


The  homedoc  has  been  changed  in  preparation  for  the  creation  of 


a  new  document. 


AMACHINE1A 


DPILE 


REVERSE 


docnamel'  -  homedoc 
docname2 '  «  newdoc 
docname3 '  -  none 


Filing  a  document  has  deleted  the  unfinished  newdoc  and  changed 
the  homedoc. 


d. 


DTHROW. 


AMACHINE1A 


DTHROW, 


REVERSE 


docnamel'  -  homedoc 
docname2 '  -  d 
docname3 '  -  none 


Throwing  a  document  away  affects  the  homedoc  and  the  document 
removed. 


e. 

PASTE. 


AMACHINE1A 

PASTEREVERSE 


docnamel'  -  whichdoc 
docname2 '  -  homedoc 
docname3 '  -  none 


Pasting  changes  the  document  pasted  Into  and  may  change  document 
length  infomation. 


AMACHINE1A 


MACHINE2 


Basis: 

Prior:  MACHINE  1 A 

Comments: 

In  this  final  level,  we  have  completely  recomposed  the  system 
components  and  have  developed  a  total  system  (le.  it  will  now  process  all 
possible  (legal  and  illegal)  user  commands).  We  also  developed  here  the 
system  control  structure  which  Interfaces  with  the  user  and  controls  the  activity 
of  the  system.  The  three  standard  system  phases  —  Initialization,  operation, 
and  termination  —  have  been  defined. 

The  provisional  user's  manual  was  taken  as  final  authority  on  the 
functioning  of  the  system  in  general  and  on  the  operation  of  the  user 
commands.  Other  decisions  reflected  in  this  level  of  specification  include 
the  final  determination  of  document  paper  size  and  the  selection  of  key  inputs 
over  a  menu  system.  The  state  space  has  been  updated  to  facilitate  system 
control  by  maintaining  a  short  history  of  key  Inputs. 

Requirements  /  Design  Decisions: 

1 1 1  All  document  papers  will  be  exactly  the  same  as  the  the  width  of  the 
screen  to  simplify  document  manipulation.  Of  course,  documents  can  be  made 
at  any  width  up  to  the  document  paper  width.  Selecting  a  document  size 
larger  than  the  screen  width  would  have  made  document  viewing  very  difficult 
on  a  fixed  width  screen  with  doubtful  Improvement  In  the  system  usefulness 
or  generality. 

|[2]|  Key  inputs  rather  than  menu  selection  will  be  used. 

|[3]|  The  decisions  about  overall  system  function  and  user  command 
functions  are  as  indicated  In  the  provisional  user's  manual  unless  a  change 
is  noted  at  the  appropriate  point  in  the  specification. 

Auxiliary  Definitions: 

a. 

arrowkeys  a  {left,  right,  up,  down,  tab) 

These  are  the  keys  which  move  the  cursor  or  give  directional 
information  to  the  commands  which  require  it. 


legalkeys  a  arrowkeys  u 

character  u  {el}  u 

{khome,  kdthrow,  kdfile,  kdcreate,  kinsert, 
kdelete,  kpaste,  kcut,  kpnc,  kprint,  kwremove, 
ksgremove,  kwcreate,  ksgcreate,  kwmove, 
ksgmove,  kwretract,  ksgretract,  kwexpand, 
ksgexpand,  kscroll,  kswap,  kchoose,  kpcreate, 
kpremove,  kcam,  kproj,  kclean,  kquit, 
krev,  kaccept} 
legalkeys  c  possiblekeys 

Here  we  have  defined  the  subset  of  possible  keys  which  are  valid 
in  this  system. 

c. 

screenkeys  a  legalkeys  -  {kdfile,  kchoose} 

Screenkeys  defines  the  set  of  user  keys  which  can  be  selected 
when  the  user  display  shows  the  tabletop. 

d. 

newkeys  a  legalkeys  -  {khome,  kdcreate,  kscroll,  kswap, 

kchoose,  kpcreate,  kpremove,  kcam, 
kproj,  kclean,  kquit,  kwremove, 
kwcreate,  kwmove} 

These  keys  are  valid  when  the  user  is  creating  a  new  document  for 
the  filing  cabinet. 


e. 

homekeys  a  arrowkeys  u  {kdthrow,  kprint,  kchoose,  kclean, 

khome,  kquit,  krev} 

This  Is  the  set  of  valid  keys  available  If  the  screen  Is  displaying  the 


home  document. 


reversekeys  a  legalkeys  -  characters  -  arrowkeys 

-  {el,  kinsert,  kdelete,  kprint,  kquit, 
krev,  kaccept} 

Some  commands  are  not  reversible.  The  set  which  are  reversible 
is  defined  by  reversekeys. 

g.  maxdocwidth  -  80 
screenlength  -  23 
screenwidth  -  80 
backcolor  -  sp 
marker  - 

These  system  constants  can  now  be  defined  based  on  known  desires 
of  the  user  or  limitations  of  the  selected  hardware. 

h. 

screendlsplay  is  ABSTRACT. 

The  policy  for  arrow  movement  of  the  cursor  is  left  undefined  at  this 
point  but  will  specify  how  the  cursor,  screen,  and  screen  document  react 
to  movement  of  the  cursor  on  the  screen. 

State  Definition: 

MACHINE 2 _ 

MACHINE1A  (DOCUMENTCLASS  (H> 

DOCUMENTCLASS  (cols  -  maxdocwidth) ) 
newkey  :  possiblekeys 

oldkey  :  possiblekeys 

The  state  definition  is  updated  to  include  the  most  recent  previous 
reversible  user  command  and  the  current  user  command.  The  old  key  will 
be  useful  for  reversing  and  for  operations  which  are  dependent  upon  the 
history  of  the  session.  Now  the  state  will  also  require  all  documents  to  be 
the  same  width  as  the  screen. 


Operations: 


SESSIOt 


ADISK 


6DISK 1  -  INITIALIZE  (0DISK) 
EXECUTE ; 

TERMINATE 


A  session  of  the  windowing  screen  editor  includes  the  standard  three 
parts  for  a  non-contlnuous  system.  The  environment  which  exists  between 
the  sessions  of  the  system  is  modeled  by  the  DISK. 


INITIALIZI 


DISK 
MACHINE 2 


projbuild'  -  d  ('projbuild') 
projview'  -  d  ('projview') 
point'  -  d  ('point') 
sstart'  -  first  (d  ('view')) 
pro j '  -  fifth  (d  ('view')) 
cam'  -  fourth  (d  ('view')) 
cursor'  -  second  (d  ('view')) 
screendoff  -  third  (d  ('view')) 
insertmode'  -  false 
arrowcommand '  -  false 
start'  -  o 
stop'  -  a 

msgline*  -  blankmsg 


*  I  m 


9UMACHINE 


printer'  -  <> 
docnamel'  -  none 
docname2 '  -  none 
docname3 '  -  none 


The  Initial  state  representation  Is  generally  the  same  as  the  final  state 
representation  of  the  previous  session.  However,  no  history  (previous  user 
commands)  Is  remembered  from  the  last  session. 

c . 

EXECUTE  a  DISPLAYEDMACH|N£2;  USER; 

LOOP  (OPERATE;  DISPLAYED^^,^;  USER) 

The  execution  of  the  user's  commands  includes  the  display  of  the 
screen  to  the  user  and  the  input  of  user  command  desires. 


d. 

USER _ 

♦MACHINE1A 
newkey, 
newkey ' , 
oldkey, 

oldkey'  :  posaiblekeys 


status  *  :  STATUS 


show  -  tabletop  =>  newkey'  -  r(screenkeys) 
show  -  newdoc  =>  newkey'  -  r(newkeys) 
show  -  homedoc  =>  newkey'  -  r(homekeys) 
oldkey  e  (kpaste, kpnc}  =*■ 

newkey'  -  r(arrowkeys  u  {kaccept}) 
v  NOT  arrowcommand 


oldkey 


oldkey' 


-  kwcreate  => 

newkey'  -  r( {kquit,krev, kchoose)  u 

arrowkeys ) 


-  oldkey 


status ' 


SUCCESS 


Only  certain  input  commands  are  allowed  by  the  system,  depending 
upon  what  Is  being  displayed  to  the  user  at  the  time  of  command  Input. 


BADKEY? - 

DMACHINEIA 
newkey , 
newkey' , 
oldkey, 

oldkey’  :  possiblekeys 

status '  :  STATUS 


show  -  tabletop  =* 

newkey'  -  r(possiblekeys-screenkeys) 
show  -  newdoc  => 

newkey'  -  r(possiblekeys-newkeys) 
show  -  homekey  *b> 

newkey'  «  r (possiblekeys-homekeys) 
oldkey  €  {kpaste,  kpnc}  ==> 

newkey'  -  r(possiblekeys-arrowkeys 

-{kaccept} ) 

a  arrowcommand 
oldkey  -  kwcreate  =» 

newkey'  -  r(poss iblekeys- 

{kquit,krev,kchoose)-arr  owkeys ) 

oldkey'  -  oldkey 

status'  -  ERROR23 


This  error  condition  traps  keys  which  are  not  allowed  due  to  the 
current  condition  of  the  display.  Consequently,  the  total  user  can  be  modeled 
by  the  following: 


USER  a  LOOP  (BADKEY?);  USER 


OPERATE  «  (KEYUPDATE  V  J(MACHINE2  |  newkey  #  kquit)); 

COMMAND 

The  operation  of  the  user  Input  command  Is  done  in  two  parts  — 
the  updating  of  Information  required  for  command  reversing  (If  new  command 
Is  reversible)  and  the  actual  command  execution. 

f . 

KEYUPDATE _ 

AMACHINE1A 
newkey, 
newkey' , 
oldkey, 
oldkey ' 

newkey  €  reversekey 

SUMACH I NE#'  -  SUMACH I NE 
oldkey'  -  newkey 
docnamel'  -  none 
docname2 '  -  none 
docname3 '  -  none 
diskl'  -  diskl  f  ran  (docdisk) 


Each  time  a  new  reversible  Key  is  accepted  as  a  potentially  legal 
command,  the  current  state  of  the  system  must  be  saved  so  that  the  system 
can  be  returned  to  that  state  if  a  reverse  is  directed.  If  the  Input  command 
Is  not  reversible,  then  the  state  before  the  most  recent  previous  reversible 


posaiblekeys 


AMACHINE1A 
newkey, 
newkey ' , 
oldkey, 

oldkey1  :  possiblekeys 

status '  :  STATUS 


newkey  »*  kquit 

(newkey  -  krev)  =>  (oldkey1  -  krev) 


(newkey  -  khome  a  show  -  tabletop)  =>  HOME 


MACHINE  1 A 


(newkey  -  khome  a  show  -  homedoc)  =>  OFFHOME 


MACHINE  1 A 


(newkey  -  kdthrow  a  show  -  newdoc) 


DTHR0Wmach.neia  td/newdoc]; 


REMOVEWI  NDOWMACH|NE1A ;  H0MEMAChineia 


(newkey  -  kdthrow  a  show  -  homedoc) 


DTHROW^cn^g^  [d/a] 


(newkey  -  kdthrow  a  show  -  tabletop) 


DTHROW..^.^..  [  d/dn  ( mas  ter  spot  ( pr  o  j  v  i  ew  ( vpno ) ) )  ] 


MACHINE1A 


(newkey  -  kdfile)  =>  DFILE 


MACHINE1A 


(newkey  -  kdcreate)  =>  DCREATE 


MACHINE1A 


(newkey  -  k insert)  =>  INSERTMODE 


MACHINE1A 


(newkey  -  kdelete)  =*  DELETE, 


MACHINE  1 A 


(newkey  -  kpaste)  =*  PASTE IT 


(newkey  -  kcut)  =*  CUT, 


MACHINE  1 A 


(newkey  -  kpnc)  =>  PASTE IT 


(newkey  -  kprint)  =*  PRINT 


MACHINE1A 


(newkey  -  kwremove)  =>  REMOVEWINDOW^^,^^ 


(newkey  -  ksgremove)  =>  REMOVESG^^,^^ 


(newkey  -  kwcreate)  =>  WCREATE; 


(newkey  -  ksgcreate)  =>  CREATESGmach|NE1a 


(newkey  -  kwmove)  => 

HOVEWINDOW^,^  [offset/ (0,0)] 


(newkey  ■  ksgmove)  ^> 

“O^MACHiNEI*  [O«=et/(0,0>] 


(newkey  -  kwretract)  =» 

SIZEWINDOWMACH|NE1A  [up/0;  down/0;  left/0;  right/0] 


(newkey  -  ksgretract) 


SIZESG 


MACHINE  1 A 


(up/0;  down/0;  left/0;  right/0] 


(newkey  -  kwexpand) 


SIZEWINDOW, 


MACHINE  1 A 


[up/0;  down/0;  left/0;  right/0] 


(newkey  -  ksgexpand) 


SIZESG^^,^^  [up/0;  down/0;  left/0;  right/0] 


(newkey  -  kscroll)  =>  SCROLL 


MACHINE1A 


[of f set/(0, 0) ] 


(newkey  -  kchoose  a  oldkey  -  kwcreate)  =*  CREATEWINDOW 


(newkey  -  kchoose  a  oldkey  #  kwcreate)  =»  CHOOSE 


MACHINE1A 


(newkey  -  kpcreate)  =>  PROJCREATE^^,^^ 


(newkey  -  kpremove)  =>  PROJREMOVE^^^g^ 


(newkey  -  kswap)  =>  PROJSWAP 


MACHINE  1 A 


(newkey  -  kcam)  =>  CAMHERE 


MACHINE  1 A 


(newkey  -  kproj)  =»  PROJHERE 


MACHINE1A 


(newkey  -  kclean)  =>  CLEANMACH|NE1A;  HOMEmach|NEiA 


(newkey  -  krev  a  oldkey  c  reversekey)  =>  REV 


MACHINE1A 


(newkey  -  kaccept)  ==>  ACCEPT 


(newkey  e  arrowkeys)  =*  CURSORMOVE 


(newkey  €  character)  a  insertmode 


INSERT, 


MACHINE  1 A 


[char /newkey) 


(newkey  e  character)  a  NOT  insertmode 


ALTER, 


MACHINE  1A 


[char /newkey) 


(newkey  -•!)>»  NEWLINE 


MACHINE1A 


where  a  *  point-1  (oddit  (y  (cursor+sstart-(lf 1) ) ) ) 


When  the  command  from  the  user  is  other  than  to  terminate  the 
session,  this  operation  will  attend  to  the  command.  The  only  error  condition 
not  handled  by  the  individual  key  operations  Is  the  case  where  there  is  nothing 
to  reverse  and  the  user  has  directed  that  a  reverse  be  done.  This  is  taken 
care  of  by  the  following  error  condition: 


NOTH I NGTORE VERSE ? _ 

AMACH INE1A 
newkey, 
newkey' , 
oldkey, 

oldkey'  :  possiblekeys 

status '  :  STATUS 


newkey  -  krev 
oldkey  i  reversekey 

status '  -  ERR0R9 


h. 


TERMINATE 


m  : 

MACHINE1A 

newkey  : 

possiblekeys 

oldkey  : 

possiblekeys 

d'  : 

DISK 

newkey  -  kquit 

d'  -  diskl  f  ran 

(docdisk)  0 

{'projview*  |— *  projview, 
'projbuild'  projbuild, 
'point'  |— >  point, 

'view'  H*  <sstart, cursor , 
screendof f , cam, pro j> 


If  the  user  has  commanded  the  termination  of  the  system  then  this 


operation  will  complete  the  session  by  saving  the  Important  parts  of  the  state 
In  the  environment. 


CURSORMO\ 


AMACHINE1A 

newkey, 

oldkey 


legalkeys 


arrowconunand  a 


((oldkey  -  kwmove) 


MOVEWINDOW^,^  [of f set/(a,b)  ] 


arrowconunand  A 


(oldkey  -  ksgmove) 


MOVESG 


MACHINE  1 A 


[of f set/(a,b) ] 


arrowconunand  A 


(oldkey  -  kwexpand) 
SIZEWINDOW. 


MACHINE  1A 

[up/c;  down/d;  left/e?  right/f] 


arrowconunand  a 


(oldkey  -  kwretract) 


SIZEWINDOW, 


MACHINE  1A 


[up/g;  down/h;  left/i;  right/;)] 


arrowconunand  a 


(oldkey  -  ksgexpand) 


SIZESG 


MACHINE  1 A 


[up/c;  down/d;  left/e;  right/f] 


arrowconunand  a 


(oldkey  -  ksgretract) 


SIZESG 


MACHINE1A 


[up/g;  down/h;  left/i;  right/j] 


arrowconunand  a 


(oldkey  -  kscroll)  => 

scrollmach.neia  [offset/(a,b)]) 


(oldkey  / 

{ kwmove , ksgmove , kwexpand , ksgexpand , 
kwr etract , ksgr etract , kscroll}  v 
NOT  arrowconunand) 

A 

%%%  the  cursor  must  stay  on  the  window. (ERROR21) 
((show  e  (newdoc/homedoc)  a 
sstart+cursor-(l,l)+(a,b)  e 

aread(slavespot(z)-(0, 1) , projsize(z)+(0,l) ) ) 
v 

%%%  the  cursor  must  stay  on  the  tabletop 
area. (ERROR22) 

(show  -  tabletop  a 
sstart+cursor-(l, l)+(a,b)  € 

area( (1,1), (tablewidth, tablelength) ) ) )  => 

%%%  the  policy  for  movement  of  the  cursor,  screen,  and 
screendoc  has  not  yet  been  defined. 

(screendisplay(cursor , sstart , (a,b) , screendof f ) 
insertmode '  -  false 
oldkey  i  (kpaste,kpnc)  => 
msgline'  -  blankmsg 
oldkey  €  (kpaste,kpnc)  => 

msgline'  -  'PASTING— POSITION  WITH  ARROWS,  END 
WITH  ACCEPT') 

where 

(newkey  -  left)  =>a--lAb-0 
(newkey  -  right)  =>a-+lAb-0 
(newkey  -  up)  =>a-0Ab»-l 
(newkey  -  down)  =>a-OAb-+l 
(newkey  -  tab)  =»a-5Ab-0 

(newkey  -  left)  =»e-lAc-d-f-0 
(newkey  -  right)  =*f-lAc-d-e-0 
(newkey  -  up)  =»c-lAd-e-f-0 
(newkey  -  down)  =>d-lAc-e-f-0 
(newkey  -  tab)  =^f  -5Ac-d-e-0 


(newkey  -  right)  =>  i  *  -1  a  g  *  h  ■  j  ■  0 
(newkey  -  left)  =>  )  ■  -1  a  g  ■  h  ■  i  •  0 
(newkey  -  down)  =>  g  ■  -1  a  h  *  i  ■  j  ■  0 
(newkey  -  up)  =>h*-lAg»i*j*0 
(newkey  -  tab)  =>  i  ■  -5  a  g  ■  h  ■  j  ■  0 

z  a  projview  (novproj) 


This  operation  establishes  (albeit  abstractly)  the  effect  on  the  display 
of  moving  the  cursor  with  the  directional  commands.  Notice  that  in  some 
cases  the  use  of  the  directional  commands  will  give  directional  parameters 
to  other  operations  rather  than  directly  moving  the  cursor. 

j- 

ACCEPT _ _ _ 

AMACHINE1A 

newkey, 

oldkey  :  legalkeys 


f%%  the  cursor  must  point  to  a  window. (ERRORl) 
newkey  c  {kpaste,kpnc}  =>  (vpno  #  0  a 

NOT  innameline( projview, vpno, cursor ,sstart)  a 
%%%  the  document  cannot  become  too  long. (ERRORll) 

rows(a)  +  y(panesize(b) )  <  maxdoclength  a 
%%%  the  lines  to  be  split  by  the  paste  must  not  contain  a 
building  projection  which  would  be  disturbed. (ERROR6) 
linesok(whichdoc, cols (docdatal(whichdoc) ) , 
y(postion) ,projbuild) ) 


(newkey  -  kpaste)  =>  PASTE 


MACHINE  1 A 


(newkey  -  kpnc)  =*  PNC 


MACHINE  1 A 


arrowcommand '  •  false 


where 


a  a  dn  (masterspot  (projview  (vpno))) 
b  a  projview*  (vpno*) 


This  is  a  very  safe  operation  which  will  do  nothing  except  to  end 
a  paste  or  paste  and  cut  operation  or  stop  other  arrowcommand  operations. 


k. 


PASTE I T _ 

AMACHINElA 

newkey  :  legalkeys 


%%%  the  cursor  roust  be  in  a  window. ( ERROR1 ) 
vpno  #  0 

%%%  the  stained  glass  pane  roust  exist  in  this 
window. (ERROR2) 

panesize  (projview  (vpno))  >  (lrl) 

%%%  in  the  case  of  paste  and  cutr  the  cursor  cannot  be  in 
the  naroeline(ERRORl)  and  the  area  to  cut  roust  not  include 
shared  information. (ERRORS) 

(newkey  -  kpnc)  =*  whichdoc  *  none  a 

areaok(whichdoc, cols(docdatal(whichdoc) ) , 
a, a+y( panes ize(z) )-l,proj build) 

insertmode '  -  false 
arrowcommand'  -  true 

rosgline'  -  'PASTING— POSITION  WITH  ARROWS,  END  WITH 
ACCEPT' 

where  z  -  projview  (vpno) 

a  -  y(retv-vprojection  (z)  (startpane(z) ) ) 


This  Is  the  set  up  command  for  a  paste  or  paste  and  cut  operation. 
The  user  selects  the  area  to  be  copied  (or  cut)  with  this  command  and 
concludes  the  pasting  of  the  selected  information  with  the  ACCEPT. 

1. 

WCREATE _ 

AMACHINE1A 

%%%  the  selected  window  location  must  leave  room  for  the 
nameline  on  the  tabletop. (ERROR5) 

area(sstart , sstart+cursor- ( 1, 1) )  c 

area ( (1,2) , (tablewidth, table length) ) 

%%%  this  must  not  exceed  the  limit  on  number  of  allowable 
viewing  documents . (ERROR8) 
novproj  <  maxvproj 

start'  -  sstart 

stop'  -  sstart  +  cursor  -  (1,1) 
insertmode'  -  false 
arrowcommand '  *  false 

msgline '  -  'CHOOSE  A  DOCUMENT  TO  PROJECT,  PLEASE' 

This  is  a  set  up  operation  for  the  creation  of  new  window.  With 
this  operation  the  user  has  selected  the  window  location  and  must  now  select 
a  document  to  place  in  the  new  window. 


Status  Values 


ERROR!  a  'THE  CURSOR  IS  NOT  IN  A  WINDOW' 

ERROR2  a  'A  STAINED  GLASS  PANE  DOES  NOT  EXIST  IN  THIS 
WINDOW' 

ERROR 3  a  'THE  MASTER  OF  THIS  PROJECTION  MUST  STAY  ON  THE 
DOCUMENT ' 

ERROR4  a  'THE  STAINED  GLASS  PANE  MUST  STAY  ON  THE  WINDOW' 
ERRORS  a  'THE  WINDOW  (AND  NAMELINE)  MUST  STAY  ON  THE 
TABLETOP ' 

ERROR 6  a  'THIS  EDIT  COMMAND  WOULD  DISRUPT  SHARED 
INFORMATION' 

ERROR 7  a  'THIS  WINDOW  ALREADY  HAS  A  STAINED  GLASS  PANE' 
ERROR8  a  'THERE  IS  NO  ROOM  FOR  THE  REQUIRED  NEW  PROJECTION’ 
ERROR9  a  'THERE  IS  NO  COMMAND  TO  REVERSE  AT  THIS  TIME' 
ERRORIO  a  'THE  WINDOW  IS  TOO  LARGE  FOR  THE  INTENDED 
DOCUMENT  * 

ERROR11  a  'THE  DOCUMENT  CANNOT  EXTEND  BEYOND  ITS  ALLOWED 
LENGTH ' 

ERROR 12  a  'THE  UPDATED  LINE  WOULD  NOT  FIT  WITHIN  THE  CURRENT 
MARGINS' 

ERROR13  a  'THERE  IS  NO  ROOM  FOR  A  NEW  DOCUMENT  IN  THE  FILING 
CABINET' 

ERROR14  a  'THE  DESIGNATED  PROJECTOR  AREA  DOES  NOT  CURRENTLY 
EXIST' 

ERROR 15  a  'THE  DESIGNATED  CAMERA  AREA  DOES  NOT  CURRENTLY 
EXIST' 

ERROR16  a  'THE  INDICATED  SPOT  HAS  NO  SHARED  DATA  TO  REMOVE' 
ERROR17  a  'TWO  WINDOWS  ARE  NOT  OVERLAPPING  AT  THIS  POINT' 
ERROR18  a  'THE  NAMELINE  MUST  NOT  BECOME  INVISIBLE' 

ERROR19  a  'THE  S.  G.  PANE  CANNOT  BE  REDUCED  ANY  FURTHER  IN 
THIS  DIRECTION' 

ERROR 20  a  'THERE  IS  NOTHING  TO  DELETE' 

ERROR21  a  BUZZ 
ERROR22  a  BUZZ 
ERROR23  a  BUZZ 


V.2  Implementation  Plan. 


There  are  two  related  areas  of  the  design  which  have  not  been 
specified  —  the  display  development  and  the  disclosure  policy.  The 
algorithms  for  these  two  segments  of  the  design  will  be  discussed  In  the 
first  section  of  this  implementation  plan.  All  other  required  initial  prototype 
algorithms  are  immediate  or  obvious  from  the  design  specification.  The 
second  section  will  deal  with  a  variety  of  other  significant  details  about  the 
implementation. 

The  display  and  the  disclosure  policy. 

Although  the  APPEARANCE  observation  defines  the  appearance  of 
each  point  on  the  tabletop.  It  does  not  provide  a  practical  algorithm  for  the 
implementation  of  that  abstract  definition.  A  number  of  possible  approaches 
exist  but  they  can  generally  be  divided  Into  two  categories  —  1)  screendoc 
coordinate  definition  or  2)  viewing  projection  application.  The  former  requires 
that  each  coordinate  position  on  the  tabletop  (or  its  selected  subset, 
screendoc)  be  defined  individually.  The  latter  suggests  initializing  the 
screendoc  to  the  appropriate  background  color  and  then  placing  the  windows 
in  order  on  the  screendoc.  Both  algorithms  would  require  the  determination 
of  the  ultimate  master  for  each  coordinate  position  within  a  viewing  window. 
Either  algorithm  could  benefit  from  appropriate  speed-ups.  eg.  where  possible 
use  rows  instead  of  simple  coordinate  positions.  A  very  much  simplified 
prototype  has  shown  that  on  sparsely  windowed  displays  or  largely  windowed 
displays  with  little  overlap  of  windows,  the  second  approach  is  generally  faster. 
Since  a  highly  cluttered  tabletop  with  many  overlapping  windows  is  not  a  likely 
mode  of  utilization  for  this  system,  the  viewing  projection  application  algorithm 
appears  to  be  the  best  choice. 

Other  decisions  required  In  the  definition  of  the  display  algorithm 
Include  the  frequency  of  screen  display  refreshment,  and  the  amount  of 
screendoc  area  redefined  before  each  display  refreshment.  The  simplest 
starting  plan  would  be  to  totally  rebuild  the  screendoc  and  refresh  the  display 
after  each  user  input.  A  significant  and  almost  immediate  improvement  can 
be  gained  by  limiting  display  refreshment  to  those  valid  inputs  which  change 
the  screen.  This  would  eliminate  rebuilding  the  screen  and  refreshing  the 
display  after  error  Inputs,  many  cursor  movement  commands,  printing,  etc. 


Of  course,  total  rebuilding  of  the  screendoc  before  each  refreshment  is  the 
simplest  implementation  since  it  can  be  centralized  and  is  not  dependent  upon 
the  type  of  display  change  required.  With  this  implementation  there  Is  no 
advantage  to  having  the  screendoc  larger  than  the  screen  area. 

This  simple  base  point  (a  viewing  projection  application  driven 
screendoc  building  algorithm  with  simple  llne-at-a-tlme  speed-ups  along  with 
a  policy  of  building  and  refreshing  the  entire  screen  with  each  screen 
changing  user  command)  can  be  altered  as  necessary  to  conform  with  the 
user's  non-functional  requirements  for  the  speed  of  display  production  if 
allowed  by  remaining  memory  resources  (speed  vs  memory  trade  off). 

The  display  disclosure  policy  determines  how  (if)  the  screen  is  rebuilt 
when  the  cursor  Is  forced  to  move  by  a  user  command.  This  happens,  for 
example,  during  editing  operations  (insert,  alter)  to  advance  the  cursor  to 
the  next  character,  during  window  sizing  and  movement  to  maintain  the  cursor 
within  the  current  window,  or  with  simple  arrow  keys  designed  to  move  the 
cursor.  Two  forms  of  disclosure  are  required  by  these  various  cursor 

movement  commands  —  screendoc  disclosure  to  keep  the  cursor  on  the 

screen  and  window  disclosure  to  keep  the  cursor  on  the  current  window. 
Screendoc  disclosure  is  potentially  necessary  for  any  user  command  that 

moves  the  cursor.  Window  disclosure  is  only  required  in  operations  where 
the  cursor  is  required  to  remain  within  the  current  window  and  there  is  the 
possibility  that  the  cursor  may  be  moved  out  of  this  window  or  onto  an 
overlapping  window.  The  user  commands  which  require  this  latter  type  of 
disclosure  are:  INSERT.  ALTER.  NEWLINE,  SIZEWINDOW.  and  MOVEWINDOW. 

Screendoc  disclosure  may  require  that  the  screen  be  moved  on  the 
screendoc  or  the  screendoc  moved  on  the  tabletop.  The  policy  for  screen 
movement  is  that  the  scrolling  capability  of  the  video  display  unit  should  be 
utilized  where  possible.  Since  left  and  right  scrolling  (panning)  are  not  a 
feature  of  the  target  terminal,  and  therefore  full  screen  refreshment  will  be 
required,  panning  should  be  implemented  to  move  the  screen  slightly  more 
than  appears  immediately  necessary  in  order  to  minimize  the  number  of 

required  screen  refreshments.  Whenever  the  screendoc  Is  also  required  to 
move,  it  should  (if  possible)  have  the  current  screen  centered  within  it. 

Implementing  window  disclosure  in  operations  where  the  cursor  may 
be  forced  to  follow  the  window  (eg.  SIZEWINDOW,  MOVEWINDOW)  will  require 
the  shifting  of  window  projection  order  (strength).  The  algorithm  for  window 
reordering  should  not  affect  the  relative  strength  of  any  window  except  the 


one  to  be  disclosed  (ie.  the  remainder  of  the  display  must  be  preserved). 

The  following  predicates  of  the  state  space  and  observations  are 
relevant  to  the  implementation  of  the  display  development  and  disclosure  policy 
algorithms: 

DISPLAYED  a  F I LE -APPEARANCE ;  PROJECTED-APPEARANCE ; 
APPEARANCE;  DISPLAY-APPEARANCE 

1.  cursor  e  area((l,l),  (screenwidth, screenlength) ) 

The  cursor  stays  on  the  screen. 

2.  screendoff  e  area((l,l),  (tablewidth-sdwidth+1, 

tablelength-sdlength+1) ) 

The  screendoc  stays  on  the  tabletop. 

3.  sstart  e  aread(screendof f ,  (sdwidth-screenwidth+1, 

sdlength-screenlength+1) ) 
The  screen  stays  on  the  screendoc. 

Other  implementation  considerations: 

a.  Physical  to  logical  key  association. 

The  lack  of  adequate  user  function  key  space  can  be  solved  by  using 
a  single  key  for  corresponding  pairs  of  commands  which  affect  either  the 
window  or  the  stained  glass  pane  (ie.  move,  retract,  expand,  remove,  create.) 
This  will  reduce  by  5  the  number  of  keys  required  for  user  commands.  Of 
course,  a  second  user  Input  would  be  required  to  differentiate  window  from 
stained  glass  pane  commands. 

The  placement  of  the  various  user  key  is  left  to  the  implementation 
and  will  be  based  on  ergonomic  considerations. 

b.  Undefined  appearance. 

The  specified  system  does  not  provide  a  technique  to  trap  undefined 
coordinate  appearance  due  to  the  mutual  circularity  of  information  sharing 
projections.  The  potential  result  is  a  non-ending  search  for  an  ultimate 
master  location  and  hence  a  useless  system.  The  algorithm  to  detect  such 
problems  should  determine  if  the  search  for  an  ultimate  master  ever  identifies 
the  same  intermediate  master  location  for  a  second  time.  This  is  the  practical 
manifestation  of  mutual  circularity. 


An  even  stronger  constraint  could  be  applied  to  eliminate  the 
possibility  of  excessively  long  (but  not  necessarily  circular)  searches  lor  an 
ultimate  master.  The  list  of  intermediate  master  locations  could  be  limited, 
as  an  arbitrary  example,  to  three  times  the  number  of  allowable  building 
projections.  This  would  place  a  worst  case  limit  on  the  time  required  to 
construct  the  screendoc. 

When  a  location  on  the  screendoc  is  trapped  by  the  algorithm  to 
detect  mutual  circularity  or  limit  ultimate  master  searches,  then  a  symbolic 
(undefined)  character  should  be  taken  as  the  contents  of  that  screendoc 
location.  The  character  *?•  is  often  used  for  this  purpose. 

c.  Window  appearance. 

In  addition  to  the  specified  use  of  a  reverse  video  nameline  to  head 
a  window,  some  form  of  border  should  be  used  to  delineate  the  remaining 
three  sides.  However  these  border  markings  should  not  constitute  part  of 
the  window  information. 

d.  Non-functional  requirements. 

Due  to  the  size  of  the  required  target  machine,  there  is  a  very  real 
trade  off  among  speed  (eg.  user  command  execution  and  display  generation 
wait  time),  the  limited  main  memory  space,  and  capability  (eg.  the  number 
of  projections  and  documents  allowed).  The  best  ultimate  balance  of  these 
factors  is  impossible  to  determine  until  a  fairly  complete  prototype  has  been 
developed  for  user  tests.  However,  early  prototypes  ([Richardson. 81]  and 
[Richardson. 82]  have  given  valuable  insight  into  the  appropriate  system  design 
for  the  non-functlonal  requirements.  This  Insight  is  manifested  in  the  design 
specification  as  redundant  (derived)  components  which  give  greater  flexibility 
to  the  implementation.  It  also  allows  us  to  define  a  reasonable  starting  point 
to  use  as  a  prototype  for  further  tuning  of  the  design  in  light  of  the 
non-functional  requirements.  Because  the  following  represent  only  an  Initial 
implementation  estimate,  care  must  be  taken  to  maintain  as  much  of  the 
flexibility  designed  Into  the  system  as  possible.  This  can  be  done  through 
the  use  of  good  strutured  programing  practices,  such  as  the  use  of  constants, 
modularization,  explicit  module  communication,  etc. 

1.  implementation  data  structures: 

-as  represented  in  the  design,  using  packed  arrays  or  arrays 
of  sequences  as  ARRAY 


2.  Disk  vs  main  memory: 

-homedoc  in  memory 
-screendoc  In  memory 

-ail  other  documents  on  disk  with  direct  access  capability 

3.  Constant  values: 

maxvproj  =  5 
maxbpro]  =  5 

The  user  cannot  cope  with  too  much  information  on  the  desktop  at 
once,  so  the  number  of  allowable  window  need  not  be  large.  Similarly  the 
amount  of  information  which  can  be  shared  should  not  be  excessive,  or  the 
user  will  tend  to  lose  track  of  it. 
sdwidth  =  80 
sdlength  =  23 

As  discussed  earlier,  the  initial  prototype  will  rebuild  the  screen  after 
each  user  operation  which  changes  the  screen;  therefore,  the  screendoc  need 
not  be  any  larger  than  the  screen, 
maxdocno  =  5 
maxdoclength  =  40 
tablelength  =  120 
tablewidth  =  120 

These  limits  on  the  documents  are  harsh  but  provide  a  reasonable 
starting  point  for  non-functional  requirement  testing. 

4.  Speed-ups: 

Prototypes  reveal  that  some  speed-up  will  be  necessary  in  two  areas: 
display  creation  and  refreshment,  and  editing  commands.  The  initial  display 
speed-up  are  discussed  above.  Other  display  speed-ups  will  require  the  reuse 
of  information  gained  in  previous  display  generations.  For  example 
regeneration  of  only  affected  parts  of  the  screendoc.  screendoc  larger  than 
screen  to  save  redefining  screendoc  for  each  small  screen  movement, 
permanent  tables  reflecting  VPNOs  or  reverse  video  *on*  for  the  screendoc 
area.  etc.  are  potential  speed-ups  which  will  need  to  weighed  against  the 
space  required  to  produce  them. 

Since  (initially  at  least)  all  documents  will  be  held  on  disk,  each 
editing  command  will  require  one  disk  access  and  often  more.  For  simple 
commands  such  as  Insert,  alter,  and  delete,  this  is  likely  to  be  prohibitively 
slow.  The  natural  speed-up  here  would  be  to  hold  part  or  ail  of  the  document 
being  edited  in  main  memory  and  only  update  the  disk  as  required. 


CHAPTER  VI 


Comparison  of  Methodologies 

This  chapter  compares  the  proposed  methodology  against  the  criteria 
developed  in  Chapter  II  and  assesses  two  other  methodologies  of  interest. 

VI.  1  Analysis  of  the  Case  Study. 

We  shall  begin  the  critique  of  the  methodology  by  viewing  our 
experience  in  the  case  study  in  light  of  the  criteria  previously  noted.  Where 
necessary  we  shall  attempt  to  scale  up  our  case  study  experience  to  allow 
us  to  at  least  generalize  about  utilizing  the  methodology  in  large  system 
developments. 

a.  Against  the  Criteria. 

Creativity  and  Cumulativity.  In  the  case  study,  the  hierarchical 
framework  with  the  limitative  approach  provided  approximately  the  desired 
degree  of  guidance  and  control.  Only  occasionally  was  there  a  dilemma  about 
how  to  progress  to  the  next  level  of  design.  These  dilemmas  were  usually 
caused  by  an  Improper  decision  or  design  step  taken  earlier.  In  these 
instances  backtracking  was  required  but  was  greatly  facilitated  by  the  vertically 
structured  decision  levels.  Certainly,  experience  with  the  design  technique 
will  remove  some  of  the  requirement  for  backtracking,  it  also  appears  that 
defining  very  abstract  initial  designs  will  require  some  experience  since  this 
is  not  something  we  have  done  in  other  design  techniques.  The  initial  design 
definition  coupled  with  the  horizontal  decomposition  is  certainly  the  step  which 
will  require  the  most  ability,  at  least  until  a  good  abstraction  library  becomes 
available. 

The  reapplication  of  abstract  components  (as  with  thp  editor)  was  very 
simple  and  saved  considerable  time.  An  unexpected  benefit  derived  from 
the  attempt  to  improve  the  cumulativity  of  software  design  was  the  ease  with 


which  the  resultant  system  could  be  adapted  for  variations  In  some  of  the 
non-functlonal  requirements.  For  example,  a  whole  spectrum  of  storage 
space/execution  time  relationships  could  have  been  defined  with  only  minor 
changes  to  the  constant  definitions  or  implementation  plan.  This  added  benefit 
appears  to  result  from  the  delaying  of  unnecessary  decisions  (like  constant 
values)  and  the  Inclusion  of  redundant  (derived)  components  within  the  state 
space.  Such  ability  to  design  a  family  of  programs  in  this  way  leads  us 
to  the  possibility  of  using  the  methodology  to  design  systems  for  mass 
production  and  allow  minor  modifications  for  the  various  clients'  requirements. 
This  would  be  similar  to  the  automobile  industry  where  the  customer  orders 
a  car  with  one  of  a  number  of  different  engines,  automatic  or  manual 
transmission,  disk  or  drum  brakes,  etc. 

Reliability.  Without  following  the  case  study  product  through  the 
remainder  of  its  life,  it  is  not  possible  to  give  absolute  evidence  about  its 
reliability.  However,  the  general  point  we  can  check  Is:  did  the  methodology 
help  to  prevent  errors  or  correct  them  early  (ie.  did  the  methodology  reduce 
the  cost  of  our  required  level  of  reliability?)  Even  though  our  required  level 
of  reliability  did  not  necessitate  the  use  of  formal  verification,  the  case  study 
was  Implemented  with  only  one  minor  design  error  being  detected.  (The 
SIZEWINDOW  operation  did  not  adjust  the  master  spot  to  coincide  with  the 
required  adjustments  to  the  slavespot.)  This  error  was  Immediately 
corrected.  Because  of  the  design  desclpline  Imposed  by  the  methodology, 
a  number  of  would-be  errors  were  detected  before  they  could  be  propogated 
to  lower  levels  of  design.  We  agree  with  [Berg. 82:153]  that  "the  disciplines 
imposed  by  writing  a  formal  specification  lead  to  very  modular  and 
straightforward  programs.* 

No  expensive  errors  —  those  at  the  system  level  rather  than  just 
within  an  algorithm  —  were  found.  In  large  measure  this  Is  due  to  the 
requirement  to  recompose  the  various  system  components  to  ensure  that  they 
fit  together  to  create  the  required  system,  in  larger  systems,  achievement 
of  such  component  compatibility  (to  each  other  and  the  system  as  a  whole) 
will  require  considerably  more  management  control  than  was  necessary  In 
the  case  study.  (See  the  discussion  on  manageability  below.) 

The  value  of  informal  reviews  of  formal  products  (ie.  at  the  abstract 
and  detailed  baseline  design  reviews)  was  not  tested  in  this  case  study 
development.  Since  this  Is  not  a  common  practice,  further  research  Is 
required  to  determine  its  effectiveness  in  the  enhancement  of  system  reliability. 


This  is  especially  true  since  we  propose  to  let  this  Informal  review  guide 
at  least  some  of  the  formal  verification. 

Requirement  evolution.  Evolution  of  functional  requirements  was  only 
simulated  In  the  case  study  and  therefore  It  Is  difficult  to  make  generalizations 
on  this  criterion  based  on  the  case  study  experience.  However,  the  emphasis 
on  validating  the  requirements  in  tandem  with  producing  the  design  has  had 
the  beneficial  effect  of  concentrating  the  design  effort  on  the  very  earliest 
phases  of  the  lifecycle. 

The  provisional  user's  manual  as  a  prototype  mechanism  to  direct 
the  requirements  evolution  was  very  useful  from  the  designer's  viewpoint. 
(Again,  since  there  was  no  real  client,  we  can  not  comment  on  the  client's 
perspective.)  Although  the  user's  manual  took  a  significant  amount  of  time 
to  write,  it  was  time  well  spent  early  in  the  design  cycle.  It  forced 
consideration  of  a  multitude  of  possible  problems/situatlons  and  was  a  valuable 
guide  in  the  lower  levels  of  design.  Of  course,  most  of  the  effort  spent  on 
the  provisional  user's  manual  will  be  directly  beneficial  to  the  final  user's 
documentation.  In  general.  Boehm  agrees  with  this  assessment:  "writing  test 
plans  and  draft  user's  manuals  tends  to  increase  the  cost  of  the  requirements 
and  design  phases  and  significantly  decrease  the  costs  of  testing  and 
maintenance  phases.‘(Boehm.81  ;46] 

However,  one  general  criticism  has  been  leveled  at  look  ahead 
techniques  such  as  the  provisional  user's  manual. [Horning, 81]  That  criticism 
suggests  that  such  techniques  can  generate  designs  that  are  untmplementable 
or  prohibitably  expensive  to  Implement.  While  that  danger  certainly  exists, 
the  formalism  and  the  limitative  approach  of  this  methodology  helps  to 
couteract  the  evolution  of  an  unrealistic  design.  Additionally,  the  use  of 
prototypes  (Horning's  proposed  technique  to  replace  look  aheads)  is  also 
advocated  in  this  methodology  and  can  be  used  with  the  provisional  user's 
manual  to  check  potential  Implementation  difficulties. 

Through  the  Lifecycle.  As  can  be  noted  in  the  case  study,  the 
transition  from  decomposed  problem  to  the  high  level  abstract  design  was 
greatly  aided  by  the  existence  of  previous  abstract  designs  (eg.  the  editor). 
The  representational  transformation  at  the  other  end  of  design  was  aided  by 
the  Implementation  plan.  Consequently,  the  goal  of  smoothing  representational 
and  phase  translstions  in  the  design  has  been  met  In  this  methodology. 


Although  the  case  study  was  not  extended  Into  the  later  phases  of 
the  lifecycle,  the  products  produced  In  the  demonstrated  phases  would 
certainly  continue  to  be  useful  later  in  the  lifecycle.  The  Incremental  design 
documentation  with  Its  referencing  scheme  should  allow  the  malntalner  to  find 
those  portions  affected  by  proposed  adaptations  or  corrections;  while  resource 
usage  information  attached  to  each  vertical  module  will  give  him  a  sound 
basis  upon  which  to  estimate  the  cost  of  such  changes. 

Client  Involvement.  The  criterion  of  contlnous  client  involvement  was 
not  tested  in  the  case  study.  The  provisional  user's  manual  would  seem 
to  be  one  effective  method  of  communicating  with  the  client.  It  also  appears 
that  the  Comments  and  Requirements  portions  of  the  template  along  with 
introductory  comments  In  the  high  level  Initial  abstractions  (eg.  FILER)  provide 
a  very  good  basis  for  the  required  Intermediate  client  documentation.  The 
frequency  and  level  of  Interaction  with  the  client  Is  In  the  purview  of  the 
design  manager  and  is  based  on  the  ability  of  the  client  and  the  complexity 
of  the  system.  However,  there  are  certainly  ample  user  Interface  requirements 
built  into  the  process. 

Manageability.  One  of  the  key  factors  to  be  assessed  in  the  case 
study  is  whether  the  disciplined  use  of  formal  techniques  allowed  the 
opportunity  for  management  control  and  visibility  of  the  Intermediate  stages 
of  the  development  —  that  Is.  are  the  management  and  formal  techniques 
mutually  supportive? 

Certainly  the  baselines  Indicated  In  the  case  project  represent 
excellent  opportunities  to  determine  the  progress  and  correctness  of  the 
design.  The  hierarchical  nature  of  the  design  with  decisions  explicitly  noted 
in  the  required  documentation  (the  template)  gives  a  much  finer  grain  of  detail 
for  management  control  between  baselines.  This  two  level  approach  to  the 
management  control  of  the  development  would  seem  to  provide  sufficient 
opportunity  for  management  to  direct  the  development  to  the  best  compromise 
among  the  various  development  goals  (including  budgetary  goals). 

Finally,  as  noted  earlier,  it  is  important  to  Insure  that  sufficient  control 
can  be  afforded  to  the  expensive  area  of  formal  verification.  The  separation 
of  formal  verification  from  the  design  effort  will  allow  special  management 
attention  to  be  given  to  the  level  and  cost  of  verification  for  each  component. 

Just  as  baselines  and  vertical  level  documentation  provided  two  layers 
of  control  and  visibility,  the  milestones  and  accounting  information  on  the 


template  provide  two  layers  of  budgeting  control.  However,  due  to  the 
evolutionary  formulation  of  requirements,  providing  Initial  resource  estimates 
may  be  difficult  in  large  system  developments.  Only  experience  on  a  larger 
scale  will  determine  If  such  estimates  are  more  difficult  or  less  accurate  then 
Initial  resource  estimates  in  other  methodologies. 

With  no  participant  interactions  In  the  case  study  we  can  only 
generalize  about  the  effectiveness  of  communication  among  participants  of 
a  large  project.  The  recording  of  Individual  decisions  In  both  formal  and 
Informal  notation  (and  relating  the  two)  certainly  enhances  the  communication 
of  technical  information  about  the  design.  The  use  of  natural  language  as 
explanation  of  other  portions  of  the  formal  design  (eg.  auxiliary  definitions, 
operations,  etc.)  also  has  this  desired  effect.  Because  of  this,  the  template 
documentation  promises  to  provide  effective  communication  to  all  participants 
in  the  design  process  except  the  client. 

in  the  case  study,  we  found  the  use  of  the  template  to  be  easy  and 
effective  in  keeping  the  documentation  current  with  the  design.  The  only 
difficulty  came  In  the  last  stage  of  design  where  the  number  of  required 
decisions  went  up  drastically  and  their  Individual  significance  fell.  From  this 
experience  we  suggest  that  there  may  be  a  point  after  which  the  explicit 
documentation  of  a  number  of  small  decisions  is  best  left  to  a  narrative  which 
explains  them  en  masse  (eg.  a  section  of  the  provisional  user's  manual.) 
In  the  stepwise  refinement  of  any  large  system  we  can  expect  that  at  least 
some  of  the  steps  must  be  large  —  usually  the  final  ones. 

One  final  manageability  consideration  is  the  selection  of  a  design  team 
structure  which  would  best  suit  the  communication  and  other  management 
requirements  of  this  methodology,  it  seems  that  a  chief  programmer  teams 
style  organization  with  an  active  manager  and  limited  number  of  specialized 
members  best  matches  the  structure  of  the  methodology. 

b.  Problems. 

In  addition  to  problems  noted  and  recommendations  made  in  the  last 
section,  a  few  other  points  need  further  consideration. 

First,  we  need  to  emphasize  or.  In  some  cases,  determine  the  limits 
of  the  methodology's  usefulness.  It  is  fairly  obvious  that  the  presented 
techniques  are  too  sophisticated  for  use  on  very  simple  projects;  however, 
it  is  not  obvious  just  how  large  a  suitable  project  must  be.  The  methodology 
does  not  intend  to  guide  the  hardware  aspects  of  a  total  system  design  or 


software  design  for  parallel  systems.  We  have  insufficient  experience  to 
suggest  which  other  types  of  applications  (if  any)  are  not  easily  designed 
in  this  methodology. 

Secondly,  it  is  not  yet  possible  for  us  to  tell  the  cost  of  training  design 
participants  and  management  in  the  techniques  of  the  methodology.  It  Is 
obvious,  however,  that  this  methodology  will  be  Initially  more  difficult  to  learn 
and  use  than  some  of  the  non-lntegrated  methodologies  (eg.  the  USAF 
methodology.)  There  may  be  a  hidden  cost  associated  with  changing  an 
organization  to  the  personnel  structure  and  management  organization  required 
by  this  methodology.  There  Is  also  some  reason  for  concern  that  we  are 
requiring  too  much  of  the  project  manager  since  we  are  adding  a  formal 
notation,  logic,  and  the  ability  to  abstract  to  his  already  substantial  burden. 

Thirdly,  the  volume  of  the  case  study  documentation  demonstrates 
that  some  automated  support  is  required  for  the  techniques  to  be  viable  In 
large  system  developments.  This  automation  must  include  at  least  an  editor 
and  a  hierarchical  database  system.  A  number  of  other  useful  automated 
tools  are  listed  Section  VII.2.  Future  Research. 

Fourthly,  one  of  the  important  attributes  of  formal  design  Is  the  ability 
to  hide  previous  levels  of  vertical  decomposition  for  the  sake  of  simplicity. 
However,  this  advantage  becomes  a  disadvantage  at  those  times  when  you 
wish  to  view  the  state  space  with  all  of  Its  predicates  and  auxiliary  definitions. 
At  these  times  it  becomes  necessary  to  'mentally  recompose*  the  appropriate 
vertical  levels.  Since  this  Is  strictly  a  textual  operation,  it  would  be  very 
useful  to  have  some  automated  assistance  In  vertical  recomposition. 

Finally.  It  appears  likely  that  a  number  of  syntactical  equivalences 
or  notational  extensions  would  be  useful  in  making  the  formalisms  more 
understandable  and  easier  to  construct.  One  obvious  Instance  of  this  in  the 
case  study  was  the  specification  of  error  conditions.  A  second  example  was 
the  component  'no  change’  specification  in  the  operations.  In  both  of  these 
cases,  we  created  a  new  convention  to  simplify  the  specification  writing  but 
both  should  be  handled  in  a  standard  way  In  the  notation.  Another  extension 
we  would  prefer  to  have  in  the  notation  is  the  more  readable  IF. ..THEN..  ELSE... 
form  of  the  alternative. 


VI. 2  The  Hierarchical  Development  Methodology. 

(Unless  otherwise  noted,  the  details  ot  the  Hierarchical  Development 
Methodology  are  taken  from  (Sllverberg;  Robinson. 78;  Robinson. 79].) 

The  Hierarchical  Development  Methodology  of  SRI  International  has 
as  its  goal  the  design  and  development  of  large  scale  software  systems  using 
formal  techniques  in  an  Integrated  approach.  It  Is.  in  a  number  of  respects, 
similar  to  the  methodology  we  proposed  In  this  thesis.  The  differences, 
however,  are  Important  ones  and  will  become  evident  as  we  describe  HDM. 

The  comprehensive  approach  of  HDM  can  be  explained  by  reviewing 
four  aspects  of  the  development  process: 

1.  Structuring  concepts. 

2.  Process  guidelines  and  milestones  (stages). 

3.  Languages.  -  and 

4.  On-line  tools. 

Structuring  concepts. 

The  structuring  concepts  of  HDM  pertain  to  the  development  process 
itself  and  the  resultant  software  systems.  A  system  in  development  will  be 
decomposed  (vertically)  Into  a  sequence  of  abstract  machines,  each  of  which 
provides  a  complete  set  of  facilities  to  the  next  higher  level.  The  top  level 
machine  facilities  are  available  to  the  user;  the  lowest  level  (primitive  machine) 
facilities  are  those  provided  by  the  environment  (eg.  concrete  machine, 
operating  system,  high  order  languanges.  etc.)  The  user  machine  and  the 
primitive  machine  are  collectively  called  the  extreme  machines. 

Within  each  vertical  level.  HDM  allows  horizontal  encapsulation 
(modularization)  of  closely  related  capabilities.  This  means  that  each  vertical 
level  of  decomposition  will  have  a  different  horizontal  decomposition.  Our 
approach  was  to  decompose  horizontally  first  with  a  different  sequence  of 
vertical  levels  for  each  horizontal  module.  We  also  consider  the  abstract 
machine  to  be  the  basic  unit  of  the  design  process,  while  HDM  holds  the 
modules  describing  the  abstract  machine  to  be  basic.  However,  the  reasons 
for  the  horizontal  decomposition  are  the  same  in  both  methodologies:  to  allow 
component  substitution,  to  contain  the  effects  of  likely  requirement  changes, 
and  to  aid  the  structuring  and  simplicity  of  the  design  process.  The  different 
methods  of  hierarchical  structuring  indicate  a  significant  difference  in 
emphasis  in  the  two  methodologies  which  will  be  explained  in  detail  later. 


Process  guidelines. 

The  guidelines  included  In  the  HDM  development  process  are  the 
following: 

1.  Decisions  must  be  recorded  as  they  are  made.  This  requirement 
is  for  both  a  formal  and  an  optional  informal  statement  of  the  decision  but 
no  correlation  Is  attempted  between  the  two  forms  to  aid  readability  of  the 
formal  statement.  Also,  the  designer  is  encouraged  to  record  informally  any 
decisions  he  has  made  even  if  the  decision  will  not  currently  be  reflected 
in  the  formal  specifications. 

2.  Decisions  are  to  be  made  In  favor  of  generality  and  adaptability. 
Parameterized  abstractions,  use  of  abstract  constant  representations,  and 
Judiciously  postponed  decisions  are  features  of  HDM  which  are  also  important 
in  our  methodology. 

3.  Minimize  the  dependency  of  decisions  on  other  decisions  and 
encapsulate  related  decisions  into  common  units.  Both  methodologies  attempt 
to  decouple  the  design  modules.  Where  the  modules  are  not  independent. 
HDM  requires  informal  definition  of  the  module  interconnections  within  an 
abstract  machine.  in  our  methodology,  the  modules  are  the  abstract 
machines. 

4.  Make  explicit  all  sharing  of  decisions.  In  HDM.  if  state  design 
decisions  affect  more  than  one  module  of  an  abstract  machine,  then  the 
cross-referencing  of  shared  decisions  must  be  noted. 

The  stages. 

The  following  stages  and  their  associated  milestones  are  the 
components  of  the  HDM  design  process: 

1.  Conceptualization. 

Conceptualization  is  the  determination  of  the  problem  to  be  solved. 
The  constraints  of  the  system  will  be  stated  as  precisely  as  possible  in  terms 
of  user's  requirements  and  environmental  (hardware,  implementation  language, 
etc.)  requirements.  These  requirements  are  stated  in  natural  language. 

This  clearly  demonstrates  the  difference  in  emphasis  alluded  to  earlier 
between  HDM  and  our  methodology.  We  developed  the  criterion  that  the 
requirement  definition  must  be  an  evolutionary  process.  Consequently,  we 
advocated  a  very  abstract  initial  design  to  simplify  the  translation  of  Informal 
requirements  and  to  allow  explicit  statement  of  ail  design  decisions  in  the 
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simultaneous  derivation  of  requirements  and  system  design.  We  feel  the  plan 
to  Initially  define  not  only  the  total  requirements  of  the  system  but  also  the 
underlying  environment,  does  not  give  proper  Importance  to  the  requirements 
definition  process.  As  we  noted  in  Chapter  II.  the  'precise*  statement  of  a 
problem  definition  is  often  very  difficult  or  impossible  at  the  outset  of  a  design 
process. 

2.  Definition  of  the  extreme  machines. 

in  this  stage  the  extreme  machines  determined  in  the  conceptualization 
are  further  defined  Informally  using  the  Hierarchy  Specification  Language 
(HSL).  The  machines  are  vertically  decomposed  Into  modules,  the  names 
of  the  data  structures  and  operations  are  listed  for  each  module,  and  a 
description  of  the  module  interconnections  are  produced.  The  prose 
description  conveys  the  decisions  which  were  in  the  designer's  mind  as  he 
was  defining  the  organization  of  the  machines. 

This  initial  definition  of  the  abstract  user's  machine  and  the 
implementation  structure  presupposes  confidence  in  the  problem  definition  set 
forth  in  the  previous  stage.  We  feel  that  this  confidence  is  likely  to  be 
unfounded  without  a  more  systematic  approach  to  the  statement  of  the 
requirements,  including  the  active  involvement  of  the  client.  To  define  the 
extreme  machines  as  required  by  this  stage,  the  designer  must  abstractly 
visualize  the  complete  user's  system  with  all  of  Its  required  decisions,  he 
must  sort  the  decisions  by  effect,  and  he  must  produce  module  headings 
for  the  most  appropriate  decomposition  of  the  abstract  machine's  capabilities. 
This  early  review  of  the  abstract  design  is  an  excellent  technique  for 
determining  potentially  difficult  aspects  of  the  development  process;  however, 
due  to  the  well  documented  difficulty  of  validating  Informal  requirements,  the 
designer  cannot  be  certain  that  these  very  important  (costly  to  correct)  early 
decisions  will  lead  to  the  appropriate  system. 

3.  Definition  of  the  intermediate  machines. 

The  definition  of  the  levels  of  abstract  machines  between  the  extreme 
machines  Is  the  goal  of  this  stage.  These  Intermediate  machines  are  defined 
in  exactly  the  same  manner  as  described  above.  The  designer  must  determine 
the  number  of  Intermediate  levels  which  is  appropriate  for  a  particular  system. 
As  noted  earlier,  the  horizontal  decomposition  of  each  vertical  level  is 
independent.  The  decision  about  how  to  decompose  a  vertical  machine  level 
Is  based  mainly  on  a  concern  for  efficiency  and  algorithm  design  since  many 
of  the  design  decisions  about  capability  of  the  user's  machine  have  been 
made  in  the  previous  step.  Therefore,  the  Intermediate  machines  correspond 
closely  to  a  series  of  refinement  machines  In  our  methodology,  and  the  Idea 


of  design  by  exclusion  (or  even  Inclusion)  of  capability  (le.  advancement)  does 
not  exist.  Now  it  Is  obvious  why  our  hierarchical  structuring  differs  from  that 
of  HDM  —  our  emphasis  is  on  requirements  definition,  client  Interface,  and 
structured  system  design,  while  theirs  is  on  structured  system  refinement  and 
(as  we  shall  see)  program  verification. 

4.  Specification  of  modules. 

This  stage  formalizes  the  decisions  made  In  the  previous  two  stages. 
Each  module  of  every  abstract  machine  is  specified  in  SPECIAL.  The 
specification  includes  Initial  values  for  each  data  structure,  definition  of  all 
state  transition  operations,  and  the  enumeration  of  objects  shared  between 
iwo  modules.  It  is  this  stage  which  characterizes  the  functional  behavior  of 
an  abstract  machine.  An  abstract  machine  specification  is  derived  by 
collecting  the  specification  of  its  component  modules. 

5.  Machine  representations. 

The  fifth  stage  defines  nonprimitive  data  structures  in  terms  of  data 
structures  from  the  next  lower  level.  In  this  way.  the  state  of  each  abstact 
machine,  including  the  user's  machine,  is  defined  by  the  data  structures  of 
the  primitive  machine  through  a  series  of  mapping  functions.  These  mapping 
functions  are  written  in  SPECIAL  but  are  otherwise  equivalent  to  retrieval 
functions  between  vertical  levels  of  our  design.  At  the  end  of  this  stage 
the  "detailed*  design  is  complete. 

6.  Abstract  implementation. 

The  abstract  implementation  is  used  to  formulate  and  record  the  final 
implementation  decisions.  An  abstract  program  is  written  to  Implement  each 
specified  operation  as  a  sequence  of  Invocations  of  operations  from  the  next 
lower  level.  The  Intermediate  Level  Programming  Language  (ILPL)  is  used 
to  describe  the  abstract  programs. 

7.  Concrete  implementation. 

This  stage  creates  concrete  (machine  executable)  programs  for  each 
abstract  program  written  In  the  previous  stage.  The  ease  with  which  this 
translation  from  abstract  to  concrete  program  is  accomplished  depends  upon 
the  accuracy  of  the  Initial  primitive  machine  model.  Therefore,  the  earliest 
decisions  taken  about  the  primitive  machine  (stages  1  and  2)  will  not  come 
under  close  scrutiny  until  the  end  of  the  development  process  —  a  potentially 
dangerous  situation  but  one  which  occurs  in  some  form  in  every  methodology. 


8.  Verification. 

In  HDM,  formal  verification  takes  two  forms: 

1.  Proofs  of  the  properties  of  the  user  Interface  of  the  designed  system 

(proofs  associated  with  stages  1-4).  Experience  has  shown  that  proofs  of 

security  and  fault-tolerance  properties  can  be  constructed  based  on  the  HDM 
development  approach. 

2.  Proof  that  the  Implementation  meets  Its  specification  (proofs  associated 

with  stages  5.6,  and  7).  This  form  of  verification  is  the  motivating  force 

behind  the  style  of  HDM  software  development.  The  techniques  for 

Implementation  verification  have  been  well  defined  using  the  Hoare 
pre/postcondition  assertions,  hierarchical  structuring  of  the  implementation, 
and  simple  abstract  data  assertions.  Even  so.  the  implementation  verification 
process  is  so  difficult  that  It  remains  an  optional  stage  of  HDM. 

Languages. 

Three  different  notations  are  used  In  HDM  for  different  stages  of  the 
design  process  and  a  programming  language  Is  required  for  the  system  code. 

The  most  important  HDM  language  Is  SPECIAL  (specification  and 
assertion  language).  Based  on  first  order  predicate  calculus  and  set  theory, 
SPECIAL  is  used  to  define  modules  of  the  abstract  machine  and  define  the 
mapping  relationships  between  data  structures  at  successive  levels.  Like  *Z*. 
11  supports  a  state-machine  specification  approach. 

Unlike  “Z\  SPECIAL  has  a  very  constrained  concrete  syntax  which 
is  "too  often  awkward  and  unpredictable'  tSllverberg;nj  and  the  language 
structures  (V-,  0-  +  OV-  functions)  do  not  conform  to  the  structure  of  the 
state-machine  model.  Additionally,  only  a  subset  of  the  language  has  been 
given  formal  semantics. 

SPECIAL  Is  not  balanced  In  its  abstraction  capability  —  procedural 
abstraction  is  much  more  easily  developed  than  data  abstraction.  The 
primitive  types  are  boolean,  character,  integer,  and  real;  more  complex  such 
as  records  can  be  built  into  the  primitive  machine  definition  but  abstract  types 
cannot  be  adequately  defined.  Certainly  there  Is  no  provision  for  utilizing  data 
types  from  an  abstraction  library  as  we  have  In  the  case  study. 

Finally,  the  error  handling  mechanism  built  Into  SPECIAL  will  not  allow 
a  state  change  with  an  error  return.  With  our  precondition  error  handling 
technique  we  have  not  been  similarly  constrained. 

A  second  generation  specification  language  to  replace  SPECIAL  Is 
in  design. 


The  Hierarchy  Specification  Language  (HSL)  is  used  to  describe 
abstract  machine  levels  and  the  structure  of  the  levels.  HSL  specifications 
are  used  to  record  the  sharing  of  decisions  among  modules  so  that 
consistency  of  their  specification  can  be  checked. 

The  Intermediate  Level  Programming  Language  CILPL)  describes 
abstract  programs  for  each  operation  of  every  module  In  the  design.  ILPL 
uses  data  structures  supplied  to  the  modules  of  the  primitive  machine  as 
its  ’built-in’  data  structures;  therefore,  it  is  very  simple  and  very  general. 

On-line  tools. 

There  are  several  tools  which  have  been  used  extensively  and  several 
others  which  are  in  design.  The  goal  is  to  create  a  development  environment 
which  is  supported  constantly  and  thoroughly  by  automated  support. 

The  first  several  tools  are  specification  checkers  which  enforce  the 
syntactic  consistency  of  the  SPECIAL.  HSL.  and  ILPL  specifications. 

Another  tool  with  extensive  application  in  the  Multilevel  Security 
Verifier.  This  verifier  Is  used  to  prove  that  a  design  specified  by  a  set  of 
SPECIAL  modules  statlsfles  a  requirement  for  different  levels  of  access 
security. 

Tools  which  are  still  in  development  Include  a  ’basic’  PASCAL 
verification  system,  a  module  simulation  system  for  rapid  prototyping  prior 
to  implementation,  and  a  development  data  base  system  to  track  specification 
changes  and  do  syntactic  consistency  checks  or  alert  the  designer  of  effects 
caused  by  a  change. 

Summary. 

There  are  a  number  of  basic  similarities  between  HDM  and  our 
methodology,  including  the  use  of  formalism,  a  hierarchical  structure  with 
abstraction  and  a  mechanism  to  record  design  decisions.  However,  the 
differences  between  the  two  methodologies  are  striking.  The  primary 
divergence  is  one  of  emphasis.  HDM  emphasizes  the  later  stages  of  the 
development  process  with  a  hierarchy  to  support  the  refinement  of  the  design 
and  the  formal  verification  of  the  Implementation.  Only  passing  notice  is  given 
to  the  difficulties  of  requirements  definition  and  validation  On  the  other  hand, 
we  have  assumed  that  absolute  Implementation  verification  is  not  currently 
cost  effective  and  should  be  only  one  of  the  tools  available  to  the  design 


manager.  We  also  believe  that  a  validated  implementation  Is  not  of  value 
unless  It  represents  the  solution  to  the  clients  requirements.  Therefore,  we 
have  designed  our  methodology  and  organized  its  underlying  hierarchy  to 
support  evolutionary  requirement  definition  and  validation:  we  emphasize  the 
early  part  of  the  design  process. 

Along  with  this  we  placed  great  importance  on  the  role  of  the  client 
and  the  manager  In  the  formal  design  process.  These  priorities  are  not 
obviously  manifested  in  HDM  although  some  manageability  is  Inherent  due 
to  the  incremental  nature  of  the  process.  We  also  put  an  emphasis  on 
abstraction  which  does  not  appear  In  HDM.  It  is  difficult  to  simultaneously 
design  large  families  of  systems  or  encourage  cumulativity  of  the  design 
process  using  the  Hierarchical  Development  Methodology. 

The  single  greatest  capability  available  in  HDM  which  we  are  missing 
is  early  and  precise  expression  of  the  Interfaces  between  modules  and 
between  abstract  machines.  While  this  is  an  enviable  characteristic,  the  price 
paid  to  obtain  it  in  HDM  is  high  —  the  early  design  process  should  not  be 
ignored  for  the  sake  of  convenient  module  structuring  and  interface  definition. 
However.  HDM  was  originally  created  for  operating  system  design  and  may 
be  better  suited  for  that  role  than  our  methodology  because  of  this  precision 
in  module  interface  design. 


VI.3  The  USAF  Development  Methodology. 

(Unless  otherwise  noted,  the  details  of  the  USAF  Development 
Methodology  are  taken  from  [USAF;  USAFa].) 

The  software  development  methodology  currently  In  use  by  the  United 
Stales  Air  Force  Is  predicated  on  the  management  approach  to  system  design 
(see  Chapter  I).  It  was  one  of  the  first  methodologies  to  apply  the  'waterfall* 
model  of  software  development.  The  ma|or  tenets  of  this  model  are 
[Boehm.  81  ;361: 

*1.  Each  lifecycle  phase  is  culminated  by  a  verification  and  validation 
activity  whose  objective  is  to  eliminate  as  many  problems  as  possible  in  the 
products  of  that  phase. 

2.  As  much  as  possible,  iterations  of  earlier  phase  products  are 
performed  in  the  succeeding  phase.' 

We  will  review  this  methodology  by  discussing  the  activities  and  the 
products  of  each  lifecycle  phase.  Within  these  phases  are  four  baselines, 
six  formal  reviews,  and  two  audits  which  provide  points  for  management  control 
in  the  development  process.  Standard  checklists  have  been  developed  for 
use  at  these  control  points  to  assist  the  management  of  the  design  effort. 

Documentation  (communication)  is  given  special  emphasis  in  this 
methodology.  Each  documentory  product  required  within  the  lifecycle  has 
a  predefined  format  and  style.  The  standards  Include  numbering  systems  and 
nomenclature  to  provide  a  common  reference  among  design  participants. 
While  this  rigid  adherence  to  conventions  can  be  constraining  and  even 
wasteful  at  times,  it  has  the  very  beneficial  effect  of  standardizing  the 
communication  to  facilitate  management  and  user  understanding.  Also,  the 
required  documentation  is  not  constant  for  all  developments  —  certain  of 
the  documents  are  not  required  on  developments  which  are  estimated  to  be 
below  standard  size  thresholds. 

The  most  significant  documentation  required  within  this  methodology 
is  the  specification  hierarchy,  it  is  this  succession  of  (informal)  specifications 
which  embodies  both  the  progressive  development  of  the  requirements  and 
the  evolution  of  the  design.  The  three  levels  of  specification  are: 

1.  Functional  Description  (FD) 

2.  System/subsystem  Specification  (SS) 

3.  Program  Specification  (PS) 

These  documents  will  be  explained  as  they  are  encountered  within  the 
following  lifecycle  description. 


The  Lifecycle  Phases. 

Concept  Phase.  The  input  to  this  first  phase  are  a  defined  need 
and  the  technical  data  necessary  to  delineate  this  need.  It  Is  the  objective 
of  the  concept  phase  to  define  an  affordable  system  which  Is  consistent  with 
the  requirements.  To  achieve  this  objective,  feasibility  studies  (possibly 
including  pilot  programs),  alternative  solution  comparisons,  and  risk 
assessments  are  accomplished.  From  these  preliminary  efforts  cost  estimates 
are  produced  and  priorities  are  enumerated.  If  the  needs  can  be  satisfied 
using  current  technology  under  current  budgetary  contraints,  then  initial 
milestones  and  a  schedule  for  development  are  determined. 

Substantial  effort  Is  put  into  this  Initial  phase  to  validate  the  need 
and  determine  the  feasibility  of  the  proposed  solution.  On  a  large  project, 
one  to  four  years  will  be  allocated  to  the  concept  phase.  This  heavy  front 
end  loading  of  the  lifecycle  is  In  some  respects  similar  to  the  underlying 
approach  we  have  taken  in  our  methodology:  however,  while  we  use 
abstraction  and  incremental  decision  making  to  help  us  define  the 

requirements,  the  USAF  methodology  relies  heavily  on  prototypes  and 

simulations  in  order  to  compare  alternatives. 

A  number  of  documents  are  produced  in  the  phase,  including  the 
Functional  Description  (FD).  the  Data  Automation  Request  (DAR).  and  the  Data 
Project  Directive  (DPD).  The  FD  is  the  first  element  in  the  specification 
hierarchy.  It  provides  a  detailed  description  (In  the  user's  terminology)  of 

the  system  requirements  Identified  in  the  DAR.  The  DAR  is  a  ‘conceptual 

description*  document  to  transmit  the  proposed  software  project  to  upper 
management  for  approval.  Finally,  the  DPD  specifies  management  parameters 
and  requirements  for  the  development  such  as  estimated  resource  usages, 
development  guidelines  and  constraints,  and  project  organization. 

The  concept  phase  is  terminated  by  the  functional  baseline.  The 
System  Requirements  Review  (SRR)  assesses  the  system  requirements  and 
accepts  the  FD.  The  concept  phase  checklist  includes  questions  such  as 
‘have  sufficient  trade-off  analyses  been  conducted*,  and  ‘are  objectives  and 
performance  envelopes  defined*. 

Definition  phase.  Following  the  management  decision  to  accept  the 
requirements  Identified  in  the  FD  comes  the  definition  process.  This  process 
wll|  delineate  the  system  to  be  developed.  The  technical  requirements  are 
allocated  to  individual  computer  program  configuration  Items  (CPCls).  the 
functional  description  is  updated,  and  the  second  level  of  the  specification 


hierarchy,  the  system/subsystem  specification  (SS)  is  generated.  The  SS  is 
a  technical  document  which  governs  the  development  and  testing  of  the 
software  system.  It  defines  the  subsystem  decomposition.  CPCls  within  each 
subsystem,  and  the  interfaces  among  the  various  system  parts.  It  also 
specifies  the  performance  required  of  each  system  part.  The  SS  represents 
the  top  level  design  of  the  required  system  and  the  customer  is  closely 
involved  in  Its  creation. 

The  formal  acceptance  of  the  system/subsystem  specification  by  the 
System  Design  Review  establishes  the  allocated  baseline.  The  SDR  will 
determine  if  the  allocated  requirements  in  the  CPCls  represent  a  complete 
and  optimal  synthesis  of  system  requirements,  if  the  management  concept 
is  properly  tailored  to  the  development  program  ahead,  and  if  the  test  plan 
is  adequate  to  address  the  likely  technical  risks  Involved  In  the  design.  The 
SDR  roughly  correlates  to  the  Decomposition  Review  In  our  methodology. 
Development  phase.  The  development  phase  begins  after  management 
ratification  of  the  system  specified  In  the  allocated  baseline.  The  goal  of 
this  third  phase  is  to  design,  generate,  and  qualify  the  program  parts  (CPCls) 
Just  defined.  The  development  phase  consists  of  four  separate  parts  each 
of  which  Is  culminated  by  a  review. 

The  first  development  phase  part  is  the  preliminary  design.  Here 
the  initial  design  of  CPCls  is  accomplished  and  a  test  plan  for  each  is 
generated.  The  Preliminary  Design  Review  (PDR)  brings  the  client  and 
developer  together  to  confirm  the  Integrity  of  the  initial  design  effort  for  each 
CPCI.  The  developer  will  present  the  results  of  any  pilot  efforts  (prototypes) 
to  the  client  at  this  time.  Our  Abstract  Design  Review  corresponds  to  the 
PDR  in  that  It  seeks  client  approval  of  the  Initial  (abstract)  design  of  the 
horizontally  decomposed  components. 

The  second  part  of  the  development  phase  is  the  detailed  design  and 
Includes  the  Inltal  preparation  of  the  program  specification.  The  Initial  version 
of  the  program  specification  (PS)  defines  the  characteristics  of  a  computer 
program  In  sufficient  detail  to  permit  implementation  in  a  programming 
language.  An  updated  version  of  the  PS  will  serve  as  the  basic  document 
for  maintenance  of  the  system  design.  The  Critical  Design  Review  satisfies 
the  client  and  management  that  the  detailed  design  meets  Its  requirements 
and  that  the  design  Is  sufficiently  defined  to  begin  implementation.  (This 
corresponds  to  our  Detailed  Design  Review.) 

The  next  portion  of  development  phase  is  the  Implementation  of  the 
CPCls  and  the  development  testing  to  debug  and  partially  validate  the  CPCls. 


The  Product  Verification  Review  marks  the  end  of  this  development  phase 
part;  it  insures  that  the  impiementation  is  ready  for  validation  testing  and 
establishes  the  product  baseline.  The  PS  Is  frozen  in  this  baseline. 

The  final  portion  of  the  development  phase  consists  of  the  Integration 
of  CPCIs.  the  'formal*  validation  tests,  final  system  documentation  preparation, 
and  system  acceptance  by  the  user.  During  this  fife  cycle  segment  are  the 
two  required  audits:  the  Functional  Configuration  Audit  to  verify  that  each  CPCl 
has  achieved  the  performance  specified  for  it.  and  the  Physical  Configuration 
Audit  to  insure  the  system  as  implemented  corresponds  to  its  technical 
documentlon.  The  System  Validation  Review  (SVR)  completes  the  development 
phase  by  reviewing  the  qualified  CPCIs  and  their  documentation  prior  to 
transfer  of  system  responsibility  to  the  client  and  the  establishment  of  the 
operational  baseline. 

Our  Software  Verification  Review  compares  closely  to  the  PVR  of  the 
USAF  methodology.  However,  we  have  essentially  combined  the  effects  of 
the  two  audits  and  the  SVR  into  our  final  System  Review.  We  feel  this  Is 
reasonable  because  the  effects  of  the  formalism  will  be  to  decrease  the 
reliance  on  testing  and  also  increase  the  correctness  (as  far  as  actually 
reflecting  the  system  implementation)  of  the  system  documentation. 

Operation  phase.  In  the  final  phase  of  the  USAF  methodology  the 
client  operates  the  designed  system  based  on  the  system  documentation 
delivered  at  the  operational  baseline  and  maintains  the  system  by  reference 
to  the  program  specifications  There  has  been  no  attempt  in  this  methodology 
to  design  a  family  of  systems  or  to  structure  design  decisions  so  that 
maintenance  and  redesign  will  be  simplfied.  Indeed,  it  is  this  very  lack  of 
emphasis  on  the  techniques  and  structure  of  the  design  process  (we  mean 
design  process  in  its  narrowest  sense  here)  that  bodes  very  badly  for  the 
client's  ability  to  make  repairs  in  a  cost  effective  manner  and.  even  more 
especially,  to  adapt  the  system  to  changing  requirements. 

Summary. 

Since  we  have  used  a  modified  ’waterfall*  model  in  the  creation  of 
our  methodology,  there  are  some  similarities  to  the  USAF  methodology.  Most 
notable  are  the  use  of  reviews  to  end  the  significant  sections  of  the  lifecycle 
and  the  utilization  of  baselines  and  a  configuration  management  system  to 
maintain  control  and  visibility  of  the  design  products. 


The  most  striking  difference  between  the  two  methodologies  is 
obviously  that  the  USAF  approach  does  not  have  many  software  engineering 
features  and  no  formal  features  built  Into  it.  It  does  not  disallow  the  use 
of  these  concepts  but  It  does  not  advocate  them  either.  In  essence  then, 
the  USAF  system  is  just  a  management  framework  in  which  the  business  of 
design  can  be  accomplished  In  any  manner  the  designer  deems  appropriate. 

Our  complaint  with  this  approach  Is  two-fold.  First,  as  we  have  seen, 
not  using  the  software  engineering  techniques  Is  quite  likely  to  make  the  total 
lifecycle  costs  of  the  product  much  higher,  even  though  initial  production  cost 
may  be  less.  Secondly,  if  software  engineering  techniques,  especially  formal 
ones,  are  used  to  control  the  lifecycle  costs,  then  they  must  be  an  inherent 
part  of  the  management  philosophy  In  the  development  as  well.  That  Is.  it 
must  be  an  Integrated  methodology  not  just  coexistent  management  and  formal 
design  frameworks. 

In  our  methodology  we  have  placed  a  much  greater  emphasis  on  client 
involvement  and  have  portrayed  the  client  as  much  less  sure  of  his  needs. 
Part  of  this  difference  can  be  explained  by  the  fact  that  the  USAF  methodology 
can  expect  clients  from  a  homogeneous  background  with  a  constant  level 
of  understanding  and  expertise.  This  means  that  while  our  methodology  could 
be  used  In  place  of  the  USAF  approach,  the  reverse  would  not  be  true  in 
many  cases. 

Finally,  there  are  certainly  some  good  lessons  to  be  learned  from 
the  USAF  methodology  with  its  vast  usage  in  the  management  of  large  software 
developments.  Primary  among  these  lessons  is  the  need  to  derive  and  apply 
strict  documentation  conventions  and  review  criteria  (eg.  checklists). 
Unfortunately,  It  is  only  after  experience  with  our  own  methodology  that  we 
will  have  the  necessary  insight  to  suggest  more  detailed  documentation 
conventions  and  management  checklists. 


CHAPTER  VII 


Conclusions 

it  has  been  the  goal  of  this  thesis  to  define  and  partially  analyze 
by  case  study  the  rudiments  of  a  practical  methodology  designed  to  reduce 
the  overall  lifecycle  costs  for  large  application  software  developments.  This 
methodology  has  drawn  from  experience  gained  in  the  historical  approaches 
to  software  design  and  has  attempted  to  Improve  on  these  approaches  by 
amalgamating  selected  management  and  software  engineering  techniques. 
Our  conclusions  and  generalizations  about  the  proposed  methodology  were 
presented  in  Section  VI.  1.  Of  course,  this  by  no  means  represents  the 
completion  of  this  research:  it  Is  only  the  first  phase  in  the  methodology 
design. 

The  remainder  of  this  chapter  briefly  outlines  the  contributions  which 
have  resulted  from  the  research  to  date,  with  an  overview  of  the  possible 
future  directions  of  related  research. 

VII.  1  Contributions. 

This  study  represents  the  first  time  that  the  set  theoretical  notation, 
*Z*.  has  been  used  In  the  total  design  of  a  moderately  sized  system.  It  has 
previously  been  used  and  proven  as  a  tool  for  analysis  of  software  system 
architectures  and  as  a  means  of  documenting  existing  systems,  in  some 
Instances  we  pushed  the  limits  of  this  notation  slightly  to  accommodate  this 
new  role. 

To  aid  In  the  demonstration  and  analysis  of  our  software  methodology, 
we  designed  an  Information  sharing,  windowing  display  and  filing  system. 
The  initial  very  abstract  definition  of  the  system  represents  a  useful  aid  in 
the  design  and  documentation  of  a  large  family  of  similar  systems,  including 
those  with  graphical  capabilities. 


Certainly  the  most  significant  contribution  made  by  this  research  has 
been  to  make  a  viable  start  toward  defining  a  practical  system  for  applying 
simultaneously  the  necessary  management  and  software  engineering 
techniques  required  to  solve  the  software  dilemma. 

VII.2  Future  Research. 

The  next  phase  of  this  continuing  research  must  be  to  modify  the 
methodology  based  upon  the  conclusions  drawn  in  Section  VI.  1.  This  fine 
tuning  will  prepare  the  way  for  testing  in  a  more  realistic  environment;  that 
is,  with  a  client,  limited  resources,  multiple  designers  and  Implementors,  a 
management  interface,  etc.  Only  with  a  case  study  of  this  increased 
magnitude  will  It  be  possible  to  assess  the  effects  of  the  methodology  on 
the  lifecycle  and  development  aspects  which  determine  system  cost  (eg. 
maintenance,  reliability,  productivity,  user  satisfaction,  etc.) 

Two  other  areas  of  related  research  are  also  relevant  to  the  future 
viability  of  this  methodology.  The  first  Is  the  creation  of  various  automated 
tools  to  support  the  design  process.  These  tools  might  give  the  capability 
to: 

1.  generate  different  versions  of  the  specifications  to  meet  the  needs 
of  the  different  users  (implementors,  designers,  clients,  verifiers,  maintainers. 
etc.) 

2.  expand  the  state  space  definitions  to  explicitly  show  all  hidden 
predicates 

3.  combine  theories  according  to  theory  comblnators 

4.  'create/retrace  the  Basis  chain  to  determine  definitions  or  trace 
the  effects  of  changes  to  the  design 

5.  check  the  consistency  of  state  predicates  and  types  after 
advancement,  refinement,  or  recomposition 

8.  rapidly  create  prototypes  from  specifications. 

The  other  area  of  related  research  is  In  the  construction  of  a  library 
of  high  level  abstractions  to  be  used  as  component  starting  points  In  future 
designs.  Such  a  library  could  also  eventually  prescribe  standards  and 
techniques  for  the  combination  of  these  components.  This  research  would 
relate  very  closely  to  mode  of  software  development  seen  by  some  (eg. 
(Wasserman.821)  as  the  future  of  software  engineering. 


ADDENDUM 


Subsequent  to  the  preparation  of  this  thesis  a  very  recent  and 
substantial  study  of  software  development  methodologies  has  come  to  our 
attention. [Wasserman. 83a;  Wasserman. 83bl  That  study  was  done  ‘to 
consolidate  (past  software  development]  work  and  to  establish  a  framework 
from  which  methodologies  could  be  developed  and  enhanced*  —  especially 
with  regard  to  Ada  software  projects.  The  result  of  this  study  was  a  set 
of  general  requirements  for  a  software  development  methodology,  a  set  of 
criteria  based  upon  these  requirements  for  evaluation  of  methodologies,  and 
an  evaluation  of  24  current  software  methodologies.  .  Although  developed  In 
a  different  style  and  for  a  different  ultimate  purpose,  that  study  validates  In 
a  very  large  measure  the  criteria  and  the  methodology  set  forth  in  this  thesis. 
Especially  important  to  us  is  the  significant  reinforcement  that  work  gives  to 
our  assertion  that  a  viable  methodology  must  be  a  coherent  combination  of 
technical  and  management  techniques  spanning  the  whole  lifecycle. 

It  is  also  Interesting  to  note  that,  of  the  24  current  methodologies 
surveyed  in  that  report,  only  two  appear  to  have  a  formal  basis  which  allowed 
some  degree  of  formal  verification.  Of  these  two,  both  were  still  under 
development  and  had  not  been  tested  in  industry.  Neither  addressed 
management  issues  in  any  detail.  Obviously  the  need  for  a  unified, 
comprehensive  methodology  still  exists. 


Appendix  A 


Specification  Library 


Notation 


-**  partial  function 
X  -»*  Y  « 

{f  :  XxY  |  (Vy  :  ran(f))  fCf'^y))  -  y} 


total  function 

X— »Y«{f:X-+*Y|  dom(f)  -  X} 


>— *  total  injection 

X  >-*  Y  -  {f  :  X  -**  Y  |  f?  f_1  -  doro  (f)}  n 

X  -»  Y 


(Va,b  :  X  -+*  Y;  p  :  F(X)  ;  q  :  *>(Y)  ;  v  :  SEQ[a] ; 

C  :  X  «-+  Y) 


f  restriction 

a  t  s  -  a  •  J(X) 

■I  corestriction 

a  J  t  -  J(Y)  o  a 

\  domain  subtraction 

a  \  p  -  a  r  (X  -  p) 

/  range  subtraction 

a  /  q  -  a  i  (Y  -  q) 

•  functional  overriding 

a  •  b  -  a  \  dom  (b)  u  b 

*  closure 

a*  -  J(X)  u  (a*  o  a)  -  u{a'  I  i  :  JV} 

function  construction 

[x  |->  y]  -  { (x,y) } 


loop  looping 

loop(a)  -  J (X)  9  (loop(a)  ®  a)  -  a*  /  dom(a) 


update  functional  updating 

update(v)  -  v(l)  9  v(2)  9  ...  9  v(length(v)) 


uncurry  G  e  (X  -**  (Y  Z)) 
uncurry(G)  e  (X,Y)  -+*  Z 


0  0 


X 


r 


image 

CflpD  -  {y  :  Y  |  (3X  :  p)(xCy)} 
Lambda  abstraction 

(Xx  :  X)  (term)  -  {(x,term)  |  x  :  X) 
arbitrary  element  selection 


H  element  creation 


Schema  Comblnators 

A  schema  has  the  form: 

NAME _ 

Signature 

Predicates 


'  Schema  output  component  designator 

;  •  Schema  composition 

F;G  a  G®F 


A 


Schema  conjunction 

Merges  components  in  the  signature;  conjoins 
predicates . 
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LOOP  Schema  looping 

Multiple  functional  applications  of  a 
potentially  non-homogeneous  schema.  In  the 
following,  P  represents  a  schema  with 
homogeneous  (ie.  both  dashed  and  undashed) 
component  z,  non-homogeneous  component  a 
(input),  and  non-homogeneous  component  b* 
(output).  Underlined  components  are 
sequences  of  the  named  component  of  F. 


F 

z  : 

Z 

z '  : 

SEQO^ZJ 

a  : 

SEQ[A] 

b'  : 

SEQ[B] 

z ' (0)  -  z 

(Vn  :  JV,  | 

n  <  #z'  - 

(F[z/z'(n-l),  z'/2'(n),  a/a(n) ,  b'/b'(n)]) 


^module  Schema  promotion 

A  is  defined  in  the  vertical  level  named 
MODULE  or,  if  not  defined  there,  is  promoted 
to  that  level  from  the  most  recent  previous 
explicit  definition. 


A[n/m]  Schema  component  substitution 

Textual  replacement  of  term  n  by  term  m  within 
the  schema. 


The  array  is  a  sequence  of  lines  which  have  a 
constant  length. 


3.  FUNCTION 


FUNCTION _ 

ARRAY 


length  (a)  -  2 
(Vn, m  :  dom  (a  (1)) 

(a  (1)  (n)  -  a  (1)  (m)  =>  n  -  in) 


The  function  is  an  array  with  two  lines,  one  for  the 
domain  and  one  for  the  range.  The  positional  index  within 
the  line  relates  the  two  values.  To  be  a  function,  each 
domain 

value  must  be  unique. 

4.  FILER 

(See  Chapter  III.) 


5.  EDITOR 

(See  the  following.) 


EDITOR 


Basis: 

Forward:  EDDOC1 


Comments: 

This  Is  an  extract  from  the  display  editor  specification  developed 
[Sufrin.Slbl. 


ED00C1 


Comments: 

This  component  of  the  editor  defines  the  document  to  be  edited  and 
the  current  position  within  that  document.  Several  useful  operations  on  the 
document  are  also  defined. 

Auxiliary  Definitions: 

a.  speck*  is  ABSTRACT 

We  will  not  define  at  this  point  what  types  of  characters  are  in  the 
document. 

b.  el  €  speck* 

However.  we  do  wish  to  Insure  that  an  end  of  line  marker  does  exist 
in  the  character  set. 

State  Component  Definition: 


EDDOCJ _ 

1  :  SEQ  [  speck+  ] 

r  :  SEQ  [  speck*  ] 


Operations: 


DELETE _ 

♦EDDOC1 


t  #  <> 
1'  - 
c 


1 

tail  (r) 


This  operation  deletes  the  next  character  after  the  current  position. 


TRAVERS! 


4EDD0C1 


r  ■»  <> 


1'  -  1  *  <f irat  (r ) > 
r'  -  tail  (r) 


TRAVERSE  moves  the  current  position  one  character  down  the 


document. 


INSERT. 


4EDDOC1 


speck* 


1*  -  1  *  <c> 


This  operation  will  allow  the  addition  of  a  character  prior  to  the 
current  position. 


♦EDDOCl 


epee 


t  #  <> 

1’  -  1  *  <c> 
r’  -  tail  (r) 


This  will  replace  the  next  character  and  move  the  current  position 
by  one  place. 


new 


EDDOCl 

EDD0C1 


prior 


This  will  allow  incorrect  operations  on  the  document  to  be  reversed. 

Operations: 

a. 

UNDO _ 

•EDITOR 

new •  -  pr ior 
prior'  -  new 


With  this  operation,  changes  to  the  document  can  be  reversed  at 
any  time  prior  to  the  next  change  request.  Of  course,  the  document  changing 
operations  must  be  appropriately  promoted  to  the  EDITOR  state. 


*»•*.  ■■ 


EDOOC1A 


Prior:  EDOOC1 

Comments: 

This  refinement  changes  the  representation  of  the  editor  document 
to  the  more  familiar  array  form. 

Auxiliary  Definitions: 

a.  speck  e  speck*  -  {el} 

The  character  set  required  by  this  representation  is  still  abstract  but 
it  no  longer  Includes  the  end  of  line  character. 

b.  sp  c  speck 

The  space  must  be  a  legal  character  In  this  character  set. 


endline  :  JVt  *  ARRAY  [speck]  -** 
endline  *  (XI, doc  |  1  c  dom  (doc)) 

min  {b  :  1. .dom(doc(l) )+l  |  ( Vxx  :  dom(doc(l) ) ) 

(xx  >  b  A  doc(l)(xx)  -  sp)} 

The  end  of  any  line  In  the  document  is  defined  by  the  first  position 
In  the  line  where  It  and  all  succeeding  characters  are  blanks. 

State  Component  Definition: 


EDDOCJ 


EDDOC1 


position 


ARRAY  [  speck  ] 
PAIR  [  JV'  } 
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